I have read about scalebase but did not understand is it NoSQL database or not? Or they just well horizontal scaled SQL database?
Per wikipedia (https://en.wikipedia.org/wiki/ScaleBase) it is a distributed MySQL implementation. It supports SQL. So, by definition, it doesn't qualify as "NoSQL"
Related
I have some difficulty in understanding the terminology of NoSQL, RDBMS (where they belong, category etc).
From my understanding, you have a 'Database Management System', which has many types such as the relational and ER model.
A RDBMS is based on the relational model.
Now you have NoSQL, which is a type of Database management system, which also has many types (key/value, document store etc.)
So basically, a DBMS and NoSQL are, term wise, on the same level but have different data models?
Am I correct?
The Wikipedia article on NoSQL is very appropriate, please read it.
The short answer is that a relational database management system is any system that manages data by...relations. NoSQL is far less descriptive. It's a host of very different approaches for managing data. They really don't have much in common with one another other than that they're not RDBMS. To further confuse things, NoSQL may actually use SQL, hence why people now call it "Not Only SQL" instead of actually "No SQL".
Coming from a relational database background, I can make the transition to document oriented databases pretty quickly. Many of the most valuable "relations" are maintained by the hierarchy of the document. Many of the DODB variants of NoSQL also offer a very rich query language as well. This subset of NoSQL I think I understand.
I am looking for a good reference for designing around the database style implemented by Azure Table Storage, S3, and BigTable. It seems like all of the samples I see are trivial implementations.
Do you know of any non-trivial treatments of design in this space?
For Azure Tables specifically (Microsoft's NoSQL database) the following blog post provides some good insight and talks to a couple of patterns to consider http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
Oren Eini (alias Ayende Rahien) has written a number of blog posts about designing NoSql databases for RavenDB - his own NoSql implementation.
I guess some of it is specific to RavenDB, but lots would also apply to other NoSql databases.
I haven't been confronted with this yet, but this is what i think (very superficial and simplistic imho)
If you have a key value kind of storage and all you accesses are key lookups use the NOSQL solutions.
If you want lookups based on values (and subvalues) or have something more complicated like joins you would go for a relational solution. Transactions = relational (am not too sure if nosql solutions support that notion yet)
It also looks like NOSQL = denormalized (SQL) (i may be terribly mistaken here)
In general, any principles/guidelines/thumb rules to decide chosing the data model for your application.
There are various factors which one may use to select a DB implementation, some of them are:
Cost : NoSQL DBs lean more towards the open source , cheaper side
Scalability : NoSQL can scale better with cheaper hardware
If you have too many joins you should go for a traditional RDBMS
Consistency guarantees can vary based on the solution used w.r.t NoSQL
You can also check out the following podcast : "Episode 165: NoSQL and MongoDB with Dwight Merriman" on SE Radio.
A document store like MongoDB can do a lot more than just the storing of key-value-pairs. MongoDB has rich index and search possibilities. You can do lookups on values (and subvalues) with MongoDB quite easily.
In a document store you can store 1:n relations in the same document. That means that there is less need to do joins. I don't say "no need to do joins" but I say "less need to do joins".
NOSQL is not a particular data model or paradigm for data access. It is used to refer to any number of non-SQL database technologies, typically those designed for distributed database applications.
Denormalization is generally a relational database term. It has nothing to do with NOSQL databases, most or all of which are not relational.
in this post Stack Overflow Architecture i read about something called nosql, i didn't understand what it means, and i tried to search on google but seams that i can't get exactly whats it.
Can anyone explain what nosql means in simple words?
If you've ever worked with a database, you've probably worked with a relational database. Examples would be an Access database, SQL Server, or MySQL. When you think about tables in these kinds of databases, you generally think of a grid, like in Excel. You have to name each column of your database table, and you have to specify whether all the values in that column are integers, strings, etc. Finally, when you want to look up information in that table, you have to use a language called SQL.
A new trend is forming around non-relational databases, that is, databases that do not fall into a neat grid. You don't have to specify which things are integers and strings and booleans, etc. These types of databases are more flexible, but they don't use SQL, because they are not structured that way.
Put simply, that is why they are "NoSQL" databases.
The advantage of using a NoSQL database is that you don't have to know exactly what your data will look like ahead of time. Perhaps you have a Contacts table, but you don't know what kind of information you'll want to store about each contact. In a relational database, you need to make columns like "Name" and "Address". If you find out later on that you need a phone number, you have to add a column for that. There's no need for this kind of planning/structuring in a NoSQL database. There are also potential scaling advantages, but that is a bit controversial, so I won't make any claims there.
Disadvantages of NoSQL databases is really the lack of SQL. SQL is simple and ubiquitous. SQL allows you to slice and dice your data easier to get aggregate results, whereas it's a bit more complicated in NoSQL databases (you'll probably use things like MapReduce, for which there is a bit of a learning curve).
From the NoSQL Homepage
NoSQL is a fast, portable, relational database management system without arbitrary limits, (other than memory and processor speed) that runs under, and interacts with, the UNIX 1 Operating System. It uses the "Operator-Stream Paradigm" described in "Unix Review", March, 1991, page 24, entitled "A 4GL Language". There are a number of "operators" that each perform a unique function on the data. The "stream" is supplied by the UNIX Input/Output redirection mechanism. Therefore each operator processes some data and then passes it along to the next operator via the UNIX pipe function. This is very efficient as UNIX pipes are implemented in memory. NoSQL is compliant with the "Relational Model".
I would also see this answer on Stackoverflow.
Put simply, it means not using a relational database for data storage.
Here's a relevant article: http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_
NoSql is the new database philosophy which talks about all the shortcomings of the relational database design, particularly the problems they have in scaling up for today's demanding web environments.
NoSql is quickly evolving into a movement with new tools, software and formats coming up as alternative to SQL.
RDBMS is as ubiquitous as OOP and while both of these design methodologies solve some problems wonderfully, they don't solve all.
So think of NoSql as the functional programmin of the database world.
Was this simple enough?
NoSQL is the idea that SQL-type databases don't satisfy the demands/requirements of a heavily-used database that requires transactions be reliable and failsafe (or close to it). This ties into the ideas of ACID and CAP, both things worth looking into but not something to lose sleep over unless you run a really popular site that is transaction-heavy (ie Amazon or Ebay). To get a great start on these subjects, I suggest:
http://www.eflorenzano.com/blog/post/my-thoughts-nosql/
and
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
Something everyone considering a "nosql" approach should consider:
(I shan't risk putting the image into this post as it contains a curse word, and I don't want offensive flags. So clicker beware -- there's an f-word in there. Only click if you have a sense of humor.)
http://browsertoolkit.com/fault-tolerance.png
Found this nice article about no-sql
and this as well:
NoSQL, Yes Search
My team is looking into geospatial features offered by different database platforms.
Are all of the implementations database specific, or is there a ANSI SQL standard, or similar type of standard, which is being offered, or will be offered in the future?
I ask, because I would like the implemented code to be as database agnostic as possible (our project is written to be ANSI SQL standard).
Is there any known plan for standardization of this functionality in the future?
Currently, there are more than one specifications followed by popular proprietary and open source implementations of spatial databases:
The OpenGIS - Simple Features for SQL
ISO SQL Multimedia Specification for Spatial - ISO/IEC 13249-3:2006 - Information technology -- Database languages -- SQL multimedia and application packages -- Part 3: Spatial
PostGIS, Oracle, Microsoft SQL Server and to some limited degree MySQL, all the databases implement the standard interfaces to manipulate spatial data. However, in spite of this fairly standardized features, all databases usually differ on simple SQL level what may make the database-agnostic implementation of your solution tricky. You likely need to survey the features you are interested and compare what various vendors provide.
For example GIS extensions for MySQL and for PostgreSQL both follow OpenGIS "Simple Features Specification for SQL" standard.
I haven't tried it, but Google tells me FDO is "an open-source API for manipulating, defining and analyzing geospatial information regardless of where it is stored". It's listed on osgeo.org - a point in its favour in my opinion.
There are providers for MySQL & Oracle. Disappointingly though SQL Server and Postgis aren't listed on the FDO providers page.
The only standard I know of is http://www.opengeospatial.org/standards/sfs and I don't know how well all the spatial database extensions implement it.
there are a number of geo-databases which are accessible with hibernate spatial
Oracle10g
Postgresql
MySQL
using an abtraction layer like hibernate is a good idea anyways, if you plan to write a database agnostic application. hibernatespatial fills this gap for geo features.