I would like to know if Spatialite is considered as a NoSQL database.
What is NoSQL?
NoSQL encompasses a wide variety of different database technologies
and were developed in response to a rise in the volume of data stored
about users, objects and products, the frequency in which this data is
accessed, and performance and processing needs. Relational databases,
on the other hand, were not designed to cope with the scale and
agility challenges that face modern applications, nor were they built
to take advantage of the cheap storage and processing power available
today.
NoSQL Database Types
Document databases pair each key with a complex data structure known
as a document. Documents can contain many different key-value pairs,
or key-array pairs, or even nested documents.
Graph stores are used to store information about networks, such as
social connections. Graph stores include Neo4J and HyperGraphDB.
Key-value stores are the simplest NoSQL databases. Every single item
in the database is stored as an attribute name (or "key"), together
with its value. Examples of key-value stores are Riak and Voldemort.
Some key-value stores, such as Redis, allow each value to have a type,
such as "integer", which adds functionality.
Wide-column stores such as Cassandra and HBase are optimized for
queries over large datasets, and store columns of data together,
instead of rows.
The Benefits of NoSQL
When compared to relational databases, NoSQL databases are more
scalable and provide superior performance, and their data model
addresses several issues that the relational model is not designed to
address:
Large volumes of structured, semi-structured, and unstructured data
Agile sprints, quick iteration, and frequent code pushes
Object-oriented programming that is easy to use and flexible
Efficient, scale-out architecture instead of expensive, monolithic
architecture
Explanation is from MongoDB site
NoSQL is a very vaguely defined term (I once wrote a blog post about this issue).
But even though the definition of NoSQL is quite fuzzy, you can definitely say that SpatiaLite is not a NoSQL database. It is, in fact, not a database at all. It is just a library for using SQLite (which is a SQL database).
The library includes some utility-functions which make it easier to store and query geospatial data in SQLite. But that data is still queried with normal SQL syntax and stored in a relational manner, so you couldn't even claim that it is a NoSQL abstraction layer on a SQL database.
Related
I have read that one of the differences between rdbms and nosql databases is storing unstructured data,I know each nosql database has its own architecture and algorithms,but I want to know why rdbms cant store unstructured data?
and why nosql databases can do that,I will be really thankful if you show me a simple example so that I can understand how nosql databases do that,and what makes rdbms unable to store unstructured data.
Relational databases are based on Edgar F. Codd's relational data model which assumes strictly structured data. The whole SQL language is constructed around this model and the databases which implement it are optimized for working that way.
But in the past few years, there were attempts to add features to SQL which allow to work with unstructured data, like the SQL/XML extension which allows to store XML documents in fields of SQL tables and query their document-trees transparently.
Document-oriented databases like MongoDB or CouchDB, on the other hand, were designed from the start to work with unstructured data and their query languages were designed around this concept, so when working with unstructured data they are usually much faster and more convenient to use.
I read this question totally wrong and thought about the problem totally wrong at first (multiple locale definitions of "structured") so ignore my comments, however, MongoDB does actually store structured data. The Wikipedia definition (which may I say seems to differ across the internet in itself) is that ( http://en.wikipedia.org/wiki/Unstructured_data ):
Unstructured Data (or unstructured information) refers to information that either does not have a pre-defined data model or is not organized in a pre-defined manner.
But that is untrue for MongoDB since it actually does have one:
{
_id:{}
}
Since the _id is always required, as such it has been more accurately said by MongoDB users recently that MongoDB has a "flexible" schema and not nessecarily schemaless which is why most people say it stores unstructured data.
So yes, it does kind of store unstructured data but not totally...
Simply put, NOSQL data stores are hierarchical, variable length, highly distributed file based systems with eventual consistency. The schema is embedded in the data (or in the code but NOSQLs are not schemaless), the columns can vary from one instance to the next even in the same structure, and the size of the columns is not fixed.
Q1. Why do people often prefer to use NoSQL over RDBMS for storing data like tweets?
Q2. Is there any NoSQL database that supports a SQL-like query syntax?
A sample table for the Q1 would be:
Status
UID
Status
Timestamp
Q1:
NoSQL products are primarily known for their ability to scale (sharding and replication) and their schema-less design. Twitter uses FlockDB (a graph DB) and not an RDBMS because of that, and because it makes more sense to use graphs to describe who follows who - not because the actual text messages.
Other benefits of NoSQL include advanced querying techniques (Map/Reduce): CouchDB and RavenDB are document-oriented DBs built on top of Lucene, and therefore can offer full-text search queries out-of-the-box, something you could never do efficiently with RDBMS.
Q2:
RavenDB queries are Linq expressions, which mimics SQL syntax, and is quite identical to it.
NoSQL databases, especially MongoDB, are often a good choice for storing things like tweets because they offer very quick write speeds, fast querying, and can easily distribute large data sets across a cluster of servers.
Many NoSQL databases have their own query syntax, but some such as Hive, a data warehouse product built on top of Hadoop, do have SQL-like query languages.
For unstructured data, or for data
whose structure is dynamic (i.e. if
stored in a RDBMS, the table
structure will continually be
changed). Imagine storing data about, say films, in a database. You start off with title and director, but before long you realise you also need to save all the actors/actresses, the year --> table structure change. You then want to store similar films --> another change. For such a scenario saving data in key/value pairs may well be easier, as you simply add the new data into the existing structure (though the example you give - basically a BLOB of text - doesn't really fit that description).
Orient supports SQL-similar syntax
I have no experience with NoSQL database systems but if I would have to choose one of the most known (MongoDb, Cassandra, CouchDb, Redis), can someone describe the relevant main features/differences of every one? Is there anything I should know with regards to their capabilities that might affect the choice of NoSQL system I use>
Redis is a key-value store. You can usually insert a primitive value (int, string, bool), or an array of primitives under a single key. Retrieval of data is usually limited to query by key. These are the most basic NoSQL databases.
Cassandra is a column-family store. It's similar to a key-value store, but supports nesting of key-value pairs up to about four levels deep. Querying is limited to query by key and map-reduce functions. This type of database has a rather difficult data model (does 'supercolumn' ring any bells?) and is highly specialized for extremely large amounts of data.
MongoDB and CouchDB are both document databases. They both store JSON documents, which aren't restricted by a schema, giving you a lot of flexibility. The database allows you to query the contents of these documents, which makes it very easy to retrieve data, compared to other types of NoSQL databases. Map-reduce functions are also supported.
Martin Fabik's answer contains some good links to comparisons of MongoDB and CouchDB.
Ayende has a series of blog posts called That No SQL Thing that handles each of these types. It's a good introduction to the NoSQL concept, the different types of NoSQL databases and how to query each of them. I highly recommend you read his articles on the database types I mentioned above, they are very instructive!
I was lately doing some research on this topic. I can post you some links..
Nice categorization of NoSQL DBs.
Comparing MongoDB and CouchDB
Comparing MongoDB, CouchDB and RavenDB Part1
Comparing MongoDB, CouchDB and RavenDB Part2
I was pretty impressed by RavenDB. It supports also transactions and triggers,but the licensing is not so friendly.
Some arguments why RavenDB from Ayende (creator of RavenDB)
In addition to the other links, take a look at the Survey of Distributed Databases as well as this what if that takes a look at the characteristics of other NoSQL databases and how they respond - [MongoDB and Foursquare - What If?].
Finally, [NoSQLSummer] has a lot of good papers describing the various offerings out there and the theoretical underpinnings of each one.
There seem to be a lot of new "NoSQL" type databases out there.
Some of the popular ones are CouchDB, Cassandra and MongoDB.
What are the differences between such databases and how are they different from tradition relational databases? What are the advantages and disadvantages of picking NoSQL DBs over SQL DBs?
The term NoSQL covers a lot of different approaches to data storage ranging from the simplest key/value storage to sophisticated document databases. It's a catchy buzz word, but not very discriptive IMHO.
For a quick intro you could take a look at the Wikipedia entry for NoSQL
Agreed, the question is "not which is better," it's "which solution or set of solutions is best for this particular situation."
NoSQL covers a lot of different storage technologies such as CouchDB, MongoDB, Cassandra and Solr.
CouchDB and MongoDB store multi-dimensional data-structures. MongoDB is also schema-less. Cassandra is a column-based storage engine for fast retrieval, and Solr helps solve other problems such as faceting.
NoSQL simply refers to any storage facility which is not interacted with via SQL queries.
They are not better. NOSQL doesn't involve any new innovation or special feature. NOSQL just refers to a collection of software products that are used for certain types of application but don't necessarily have much else in common with each other. NOSQL does not have to mean a non-relational database.
Folks, Its a hot debate now a days, SQL or NoSQL, While some admire the elegance in terms of performance of NoSQL databases while others want to live with the legacy of SQL or the RDBMS. While each have its merits and demerits ,I tried to contrast it in brief using some points.
While RDBMS uses relations and joins to make data simpler in database tables
NoSQL don't use joins for performance.
NoSQL scales freely when we talk in terms of schema and data, while its very tough to scale a RDBMS if data grows.
There are restriction in size of data in RDBMS in terms of data-types capability, files of any size can be used in NoSQL databases.
Data integrity enforcement comes to play only in RDBMS not in NoSQL databases.
ACID is not the cup of tea for NoSQL databases but for RDBMS.
RDBMS supports complex transactions whereas NoSQL keeps mum for transactions.
NoSQL does not support constraints and validations while its the basic ingredient in RDBMS.
Data is not structured in NoSQL but is highly structured in form of tables in RDBMS.
Its all depends upon the nature and need of the project whether to use SQL or NoSQL.
RDBMS is completely structured way of storing data.
While the NoSQL is unstructured way of storing the data.
And another main difference is that the amount of data stored mainly depends on the Physical memory of the system. While in the NoSQL you don't have any such limits as you can scale the system horizontally.
You'll find that NoSQL database have few common characteristics. They can be roughly divided into a few categories:
key/value stores
Bigtable inspired databases (based on the Google Bigtable paper)
Dynamo inspired databases
distributed databases
document databases
Well,The basic difference are discussed below.Of course,now No-SQL concepts getting popular day by day.But still which one we need to use based on project need or requirements.
1) SQL databases are primarily called as RDBMS. whereas NoSQL database are primarily called as Non-Relational or Distributed database.
2) RDBMS will follow ACID properties i.e Atomcity,Consistency,Isolation,Durability.But in No-Sql it's following CAP (Consistency, Availability and Portioning).
3) In SQL we store data in Tabular formats only.But in No-SQL it uses collection of key-value pair, documents, graph databases or wide-column stores.So No-SQL is Schema free and It can handle structured, semi-structured and unstructured data.
But SQL is not Schema free.SQL is having Pre-Defined schema.i.e In SQL if you have table and in that first column is int data type,then you cant store string or Float values.
4) RDBMS follows SQL ( structured query language ) for defining and manipulating the data, which is very powerful. In NoSQL database, queries are focused on collection of documents. Sometimes it is also called as UnQL (Unstructured Query Language). The syntax of using UnQL varies from database to database.Also SQL databases are good fit for the complex query intensive environment whereas NoSQL databases are not good fit for complex queries. On a high-level, NoSQL don’t have standard interfaces to perform complex queries, and the queries themselves in NoSQL are not as powerful as SQL query language.
For Eg..Take Social Eng. sites,We upload photos/videos/Music/Album..etc.For that we get comments, replies to comments,like..etc.Here we can get numbers,special characters..,so almost we cant predict what might be the reply or comments.In this case we go for No-SQL in documented type like below to store the comments.
{
user_id: ObjectID("65f82bda42e7b8c76f5c1969"),
update: [
{
date: ISODate("2015-09-18T10:02:47.620Z"),
text: "Nice picture."
},
{
date: ISODate("2015-09-17T13:14:20.789Z"),
text: "1234#some smile symbol"
}
{
date: ISODate("2015-09-17T12:33:02.132Z"),
text: "...Oh my god.."
}
]
}
In Above if we go for SQL we cant store comments (text above) in column only.We need to store based on type.So we will end up with Big complex query with number of joins with different tables .But SQL is good for Transactions.
5)In most typical situations, SQL databases are Vertically scalable. You can manage increasing load by increasing the CPU, RAM, SSD, etc, on a single server. On the other hand, No-SQL databases are Horizontally scalable. You can just add few more servers easily in your No-SQL database infrastructure to handle the large traffic.
6)SQL databases are best fit for Heavy duty transnational type applications, as it is more stable and promises the atomicity as well as integrity of the data. While you can use NoSQL for transactions purpose, it is still not comparable and stable enough in high load and for complex transactional applications.
7)Examples for No-SQL are MangoDB,Cassandra..etc while for SQL are MySQL,SQL Server etc..
I'm used to using relational databases like MySQL or PostgreSQL, and combined with MVC frameworks such as Symfony, RoR or Django, and I think it works great.
But lately I've heard a lot about MongoDB which is a non-relational database, or, to quote the official definition,
a scalable, high-performance, open
source, schema-free, document-oriented
database.
I'm really interested in being on edge and want to be aware of all the options I'll have for a next project and choose the best technologies out there.
In which cases using MongoDB (or similar databases) is better than using a "classic" relational databases?
And what are the advantages of MongoDB vs MySQL in general?
Or at least, why is it so different?
If you have pointers to documentation and/or examples, it would be of great help too.
Here are some of the advantages of MongoDB for building web applications:
A document-based data model. The basic unit of storage is analogous to JSON, Python dictionaries, Ruby hashes, etc. This is a rich data structure capable of holding arrays and other documents. This means you can often represent in a single entity a construct that would require several tables to properly represent in a relational db. This is especially useful if your data is immutable.
Deep query-ability. MongoDB supports dynamic queries on documents using a document-based query language that's nearly as powerful as SQL.
No schema migrations. Since MongoDB is schema-free, your code defines your schema.
A clear path to horizontal scalability.
You'll need to read more about it and play with it to get a better idea. Here's an online demo:
http://try.mongodb.org/
There are numerous advantages.
For instance your database schema will be more scalable, you won't have to worry about migrations, the code will be more pleasant to write... For instance here's one of my model's code :
class Setting
include MongoMapper::Document
key :news_search, String, :required => true
key :is_availaible_for_iphone, :required => true, :default => false
belongs_to :movie
end
Adding a key is just adding a line of code !
There are also other advantages that will appear in the long run, like a better scallability and speed.
... But keep in mind that a non-relational database is not better than a relational one. If your database has a lot of relations and normalization, it might make little sense to use something like MongoDB. It's all about finding the right tool for the job.
For more things to read I'd recommend taking a look at "Why I think Mongo is to Databases what Rails was to Frameworks" or this post on the mongodb website. To get excited and if you speak french, take a look at this article explaining how to set up MongoDB from scratch.
Edit: I almost forgot to tell you about this railscast by Ryan. It's very interesting and makes you want to start right away!
The advantage of schema-free is that you can dump whatever your load is in it, and no one will ever have any ground for complaining about it, or for saying that it was wrong.
It also means that whatever you dump in it, remains totally void of meaning after you have done so.
Some would label that a gross disadvantage, some others won't.
The fact that a relational database has a well-established schema, is a consequence of the fact that it has a well-established set of extensional predicates, which are what allows us to attach meaning to what is recorded in the database, and which are also a necessary prerequisite for us to do so.
Without a well-established schema, no extensional predicates, and without extensional precicates, no way for the user to make any meaning out of what was stuffed in it.
My experience with Postgres and Mongo after working with both the databases in my projects .
Postgres(RDBMS)
Postgres is recommended if your future applications have a complicated schema that needs lots of joins or all the data have relations or if we have heavy writing. Postgres is open source, faster, ACID compliant and uses less memory on disk, and is all around good performant for JSON storage also and includes full serializability of transactions with 3 levels of transaction isolation.
The biggest advantage of staying with Postgres is that we have best of both worlds. We can store data into JSONB with constraints, consistency and speed. On the other hand, we can use all SQL features for other types of data. The underlying engine is very stable and copes well with a good range of data volumes. It also runs on your choice of hardware and operating system. Postgres providing NoSQL capabilities along with full transaction support, storing JSON documents with constraints on the fields data.
General Constraints for Postgres
Scaling Postgres Horizontally is significantly harder, but doable.
Fast read operations cannot be fully achieved with Postgres.
NO SQL Data Bases
Mongo DB (Wired Tiger)
MongoDB may beat Postgres in dimension of “horizontal scale”. Storing JSON is what Mongo is optimized to do. Mongo stores its data in a binary format called BSONb which is (roughly) just a binary representation of a superset of JSON. MongoDB stores objects exactly as they were designed. According to MongoDB, for write-intensive applications, Mongo says the new engine(Wired Tiger) gives users an up to 10x increase in write performance(I should try this), with 80 percent reduction in storage utilization, helping to lower costs of storage, achieve greater utilization of hardware.
General Constraints of MongoDb
The usage of a schema less storage engine leads to the problem of implicit schemas. These schemas aren’t defined by our storage engine but instead are defined based on application behavior and expectations.
Stand-alone NoSQL technologies do not meet ACID standards because they sacrifice critical data protections in favor of high throughput performance for unstructured applications. It’s not hard to apply ACID on NoSQL databases but it would make database slow and inflexible up to some extent. “Most of the NoSQL limitations were optimized in the newer versions and releases which have overcome its previous limitations up to a great extent”.
It's all about trade offs. MongoDB is fast but not ACID, it has no transactions. It is better than MySQL in some use cases and worse in others.
Bellow Lines Written in MongoDB: The Definitive Guide.
There are several good reasons:
Keeping different kinds of documents in the same collection can be a
nightmare for developers and admins. Developers need to make sure
that each query is only returning documents of a certain kind or
that the application code performing a query can handle documents of
different shapes. If we’re querying for blog posts, it’s a hassle to
weed out documents containing author data.
It is much faster to get a list of collections than to extract a
list of the types in a collection. For example, if we had a type key
in the collection that said whether each document was a “skim,”
“whole,” or “chunky monkey” document, it would be much slower to
find those three values in a single collection than to have three
separate collections and query for their names
Grouping documents of the same kind together in the same collection
allows for data locality. Getting several blog posts from a
collection containing only posts will likely require fewer disk
seeks than getting the same posts from a collection con- taining
posts and author data.
We begin to impose some structure on our documents when we create
indexes. (This is especially true in the case of unique indexes.)
These indexes are defined per collection. By putting only documents
of a single type into the same collection, we can index our
collections more efficiently
After a question of databases with textual storage), I glanced at MongoDB and similar systems.
If I understood correctly, they are supposed to be easier to use and setup, and much faster. Perhaps also more secure as the lack of SQL prevents SQL injection...
Apparently, MongoDB is used mostly for Web applications.
Basically, and they state that themselves, these databases aren't suited for complex queries, data-mining, etc. But they shine at retrieving quickly lot of flat data.
MongoDB supports search by fields, regular expression searches.Includes user defined java script functions.
MongoDB can be used as a file system, taking advantage of load balancing and data replication features over multiple machines for storing files.