Comments for ODBMS Industry Watch http://www.odbms.org/blog Trends and Information on New Data Management Technologies, Innovation. Wed, 17 Apr 2013 21:47:18 +0000 hourly 1 http://wordpress.org/?v=3.1.1 Comment on Graphs vs. SQL. Interview with Michael Blaha by Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7665 Evgeniy Grigoriev Wed, 17 Apr 2013 21:47:18 +0000 http://www.odbms.org/blog/?p=2047#comment-7665 I don't see the picture in my previous message after "When I see picture like this". I use "img" tag to insert it/ I try to do it once again and give a link. It's just an usual graph. . http://3.bp.blogspot.com/-4KrzYirz0VM/UEIqeaDuuRI/AAAAAAAAAAA/0QtrMs4PT70/s400/socnet-start.png.. I don’t see the picture in my previous message after “When I see picture like this”. I use “img” tag to insert it/ I try to do it once again and give a link. It’s just an usual graph.
.

http://3.bp.blogspot.com/-4KrzYirz0VM/UEIqeaDuuRI/AAAAAAAAAAA/0QtrMs4PT70/s400/socnet-start.png..

]]> Comment on Graphs vs. SQL. Interview with Michael Blaha by Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7664 Evgeniy Grigoriev Wed, 17 Apr 2013 21:40:20 +0000 http://www.odbms.org/blog/?p=2047#comment-7664 I would explain two my points. Point one (an graph vs. schema). Let me explain why I think that there is no opposition between graphs and schemas. When I see picture like this I understand that only two tables are enough in relational DB to present this graph even it will be million times more. We have a constant simple schema of data which describe complex graph (because of the simplicity the schema may be not defined manifestly but it exists anyway). The graph describes an object domain, the schema describe data of this object domain. These descriptions are differ, but not opposite. They are orthogonal. For me there is no sense to compare them directly or in form of systems, which implement them. Point two ("Why everybody wants and doesn't want to replace RDBMS"). For me current relational DBMS has only one drawback. Offering advantages of RM, they force users to describe object domain in terms of relational data model. "If you want to use relations you have to create the relations manifestly". For me RM itself is very formal, and according to RM, all advantages of this formality are available when all data are presented as a set of relations. Once again: all data have to be _presented_ as a set of relations (not described manifestly! So RM doesn't pretend ever to be used to describe something (inc. object domains). Better ways exist to describe objects domains. But it doesn't mean that it's necessary to throw out relational DBMS, because RM really has a big number of advantages. Unfortunately specialists who understand that RM is not good to describe object model (once again RM doesn't pretend to do it) try to forget about RM in a new DBMS at all. As a result tons of the new DBMS appear which offer to user a kind of revolution both for mentality and to practical work But all, what a most of RDBMS users need, is just an ability to describe object domain in more natural way and, then, present the object domain data in relational form. I would explain two my points.

Point one (an graph vs. schema).
Let me explain why I think that there is no opposition between graphs and schemas. When I see picture like this I understand that only two tables are enough in relational DB to present this graph even it will be million times more.

We have a constant simple schema of data which describe complex graph (because of the simplicity the schema may be not defined manifestly but it exists anyway). The graph describes an object domain, the schema describe data of this object domain. These descriptions are differ, but not opposite. They are orthogonal. For me there is no sense to compare them directly or in form of systems, which implement them.

Point two (“Why everybody wants and doesn’t want to replace RDBMS”).

For me current relational DBMS has only one drawback. Offering advantages of RM, they force users to describe object domain in terms of relational data model. “If you want to use relations you have to create the relations manifestly”. For me RM itself is very formal, and according to RM, all advantages of this formality are available when all data are presented as a set of relations. Once again: all data have to be _presented_ as a set of relations (not described manifestly! So RM doesn’t pretend ever to be used to describe something (inc. object domains).

Better ways exist to describe objects domains. But it doesn’t mean that it’s necessary to throw out relational DBMS, because RM really has a big number of advantages. Unfortunately specialists who understand that RM is not good to describe object model (once again RM doesn’t pretend to do it) try to forget about RM in a new DBMS at all. As a result tons of the new DBMS appear which offer to user a kind of revolution both for mentality and to practical work

But all, what a most of RDBMS users need, is just an ability to describe object domain in more natural way and, then, present the object domain data in relational form.

]]> Comment on Graphs vs. SQL. Interview with Michael Blaha by Reinhold Thurner, http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7661 Reinhold Thurner, Wed, 17 Apr 2013 13:28:32 +0000 http://www.odbms.org/blog/?p=2047#comment-7661 I would like to discuss the pros and cons of different approaches for "storage system" in relation to a basic reference model. Such an approach has been proposed by Peter Chen in his famous paper "The Entity-Relationship Model – Toward a Unified View of Data". His ideas provide us with the means to express the differences between DMBSs or their shortcomings in comparison to the generic model. The profile of a "storage system" can be described by (1) the existence / model of the schema, (2) the model of the instance level and (3) the functionality of the system (as e.g. ACID-support, access-language, performance). Depending on the purpose and circumstances a data store may live well without a schema and can operate without ACID or formal access-language – if it is prepared to pay the price for such a profile. A graph data base has (1) no schema – or at least not a formally defined schema. There is a sort of implicit use of a "schema" in each query - otherwise it would be impossible to define a generic search: You specify a search "Friends" that "work_together" – and not "amici" "lavorando insieme" - because you know that there are entity-types releated by relationship-types with exactly these names. On the instance level (2) graph data bases know about entities with attributes and about relationships but without attributes. They provide(3) the D(urability) of the ACID-package and a toolbox to access the instance data, but no formal, schema-related language. A relational DBMS has a (1) schema with entities and process-related relationships (constraints). The constraints can be derived from the conceptual model, but are not a complete representation of the conceptual (entity-relationship) model. On the instance-level (2) an RDBMS knows about entities (tables) and attributes (columns) but there is no equivalent to a relationship. The relationships of the conceptual model are emulated on the instance level by foreign keys or relation-tables for m:n relationships or relationships with attributes. The SQL-query-language (3) reflects the tabular schema and reestablishes relations via the interpretation of special attributes (foreign keys) in a join-operation. It is common practice to use the conceptual model only for the initial design and the creation of the first cut database; it is never really tested and not included in the evitable changes of a database. It finally "remains pinned to the wall" (Blakely) as an outdated document. The integration of (1) the (entity-relationship) based schema and (2) a congruent instance-model leads to an erDBMS. Such a DBMS stores the relationships between entity-instances and the attributes of relationships in the database. This has an impact on performance - it slows down the write process and speeds up the read access. (3) An erDBMS provides full ACID-support and has an access-language (erSQL) related to the conceptual schema. It navigates (similar to a graph database) through the structure and collects attributes controlled by an SQL-like select-statement. Schemas are extensible; changes to the schema which affect the instance data require also changes to the instance data: the structural consistency of schema and instance data is automatically enforced. An erDBMS is certainly not another form of an ORM which attempts to bridge the semantic gap between the conceptual model and the (relational) instance data. SQL-databases are undoubtedly the market leader – Stonebraker has sufficiently explained why this is the case. This may change with the combination of the erDBMS-model using in-memory storage. Our tests with Metasafe and VoltDB (as persistence layer) show promising results. I would like to discuss the pros and cons of different approaches for “storage system” in relation to a basic reference model. Such an approach has been proposed by Peter Chen in his famous paper “The Entity-Relationship Model – Toward a Unified View of Data”. His ideas provide us with the means to express the differences between DMBSs or their shortcomings in comparison to the generic model. The profile of a “storage system” can be described by (1) the existence / model of the schema, (2) the model of the instance level and (3) the functionality of the system (as e.g. ACID-support, access-language, performance). Depending on the purpose and circumstances a data store may live well without a schema and can operate without ACID or formal access-language – if it is prepared to pay the price for such a profile.
A graph data base has (1) no schema – or at least not a formally defined schema. There is a sort of implicit use of a “schema” in each query – otherwise it would be impossible to define a generic search: You specify a search “Friends” that “work_together” – and not “amici” “lavorando insieme” – because you know that there are entity-types releated by relationship-types with exactly these names. On the instance level (2) graph data bases know about entities with attributes and about relationships but without attributes. They provide(3) the D(urability) of the ACID-package and a toolbox to access the instance data, but no formal, schema-related language.
A relational DBMS has a (1) schema with entities and process-related relationships (constraints). The constraints can be derived from the conceptual model, but are not a complete representation of the conceptual (entity-relationship) model. On the instance-level (2) an RDBMS knows about entities (tables) and attributes (columns) but there is no equivalent to a relationship. The relationships of the conceptual model are emulated on the instance level by foreign keys or relation-tables for m:n relationships or relationships with attributes. The SQL-query-language (3) reflects the tabular schema and reestablishes relations via the interpretation of special attributes (foreign keys) in a join-operation. It is common practice to use the conceptual model only for the initial design and the creation of the first cut database; it is never really tested and not included in the evitable changes of a database. It finally “remains pinned to the wall” (Blakely) as an outdated document.
The integration of (1) the (entity-relationship) based schema and (2) a congruent instance-model leads to an erDBMS. Such a DBMS stores the relationships between entity-instances and the attributes of relationships in the database. This has an impact on performance – it slows down the write process and speeds up the read access. (3) An erDBMS provides full ACID-support and has an access-language (erSQL) related to the conceptual schema. It navigates (similar to a graph database) through the structure and collects attributes controlled by an SQL-like select-statement. Schemas are extensible; changes to the schema which affect the instance data require also changes to the instance data: the structural consistency of schema and instance data is automatically enforced. An erDBMS is certainly not another form of an ORM which attempts to bridge the semantic gap between the conceptual model and the (relational) instance data.
SQL-databases are undoubtedly the market leader – Stonebraker has sufficiently explained why this is the case. This may change with the combination of the erDBMS-model using in-memory storage. Our tests with Metasafe and VoltDB (as persistence layer) show promising results.

]]> Comment on Graphs vs. SQL. Interview with Michael Blaha by Evgeniy Grigoriev http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7656 Evgeniy Grigoriev Tue, 16 Apr 2013 20:53:17 +0000 http://www.odbms.org/blog/?p=2047#comment-7656 Thank you for the interview. It's very interesting for me. And it's very usual. First of all I cannot understand at all how it is possible to oppose the term "schema" to the term "graph". Michael said that graphs are well-known since a time of network databases. But the network databases always have a scheme. If I have data schema described in OO terms and I will get a graph of objects linked with references. So there is no opposition between graphs and schemas. Secondly. Michael said that "Relational databases permit navigation via joins".. I would correct this phrase as "<b>Today</b> relational DBMS permit navigation via <b>evident</b> joins" because generally relational DBMS can permit navigation without <b>evident</b> joins but with very usual navigation paths. Relations do not oppose to the navigation, it's just a drawback of existing RDBMS. And I think it's better to use term "DBMS" when we are speaking about data manipulation abilities because "database" is just big piece of data. A good news for me that "possible performance differences (between relational DBMS and other ones – EG) are often not obvious". It means when "difference in expressiveness" is the only problem. But (once again) this is not a general problem and this is not a SQL problem even (it's just a language which can be slightly extended to get new possibilities). You can visit my site http://rxo-project.com to be convinced of this. Thank you for the interview. It’s very interesting for me. And it’s very usual.

First of all I cannot understand at all how it is possible to oppose the term “schema” to the term “graph”. Michael said that graphs are well-known since a time of network databases. But the network databases always have a scheme. If I have data schema described in OO terms and I will get a graph of objects linked with references. So there is no opposition between graphs and schemas.

Secondly. Michael said that “Relational databases permit navigation via joins”.. I would correct this phrase as “Today relational DBMS permit navigation via evident joins” because generally relational DBMS can permit navigation without evident joins but with very usual navigation paths. Relations do not oppose to the navigation, it’s just a drawback of existing RDBMS.

And I think it’s better to use term “DBMS” when we are speaking about data manipulation abilities because “database” is just big piece of data.

A good news for me that “possible performance differences (between relational DBMS and other ones – EG) are often not obvious”. It means when “difference in expressiveness” is the only problem. But (once again) this is not a general problem and this is not a SQL problem even (it’s just a language which can be slightly extended to get new possibilities). You can visit my site http://rxo-project.com to be convinced of this.

]]> Comment on Graphs vs. SQL. Interview with Michael Blaha by Roberto V. Zicari http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7646 Roberto V. Zicari Mon, 15 Apr 2013 19:51:26 +0000 http://www.odbms.org/blog/?p=2047#comment-7646 How DEX relates to Graph databases? Please explain, How DEX relates to Graph databases? Please explain,

]]> Comment on Graphs vs. SQL. Interview with Michael Blaha by Pere Baleta http://www.odbms.org/blog/2013/04/graphs-vs-sql-interview-with-michael-blaha/comment-page-1/#comment-7644 Pere Baleta Mon, 15 Apr 2013 15:48:12 +0000 http://www.odbms.org/blog/?p=2047#comment-7644 Very interesting view about Graph Databases. We, at Sparsity Technologies, are the developers of DEX (http://www.sparsity-technologies.com/dex) Thanks Pere Very interesting view about Graph Databases. We, at Sparsity Technologies, are the developers of DEX (http://www.sparsity-technologies.com/dex)

Thanks
Pere

]]> Comment on One size does not fit all: “document stores”, “nosql databases” , ODBMSs. by Aeomer http://www.odbms.org/blog/2010/02/document-stores-nosql-databases-odbmss/comment-page-1/#comment-7607 Aeomer Tue, 02 Apr 2013 12:31:52 +0000 http://www.odbms.org/odbmsblog/2010/02/08/document-stores-nosql-databases-odbmss/#comment-7607 PostgreSQL supported key/value stores whiles most NoSQL devs were in diapers. (See hstore) The problems of data stores that do not need SQL like interrogation or consistency is well understood *and* already solved - NoSQL is not new, but certain storage requirements (web distributed storage) makes them more relevant now. The primary reason given for the whole array of NoSQL solutions (speed and no need for query languages) is secondary to the better reason - simple scaling of data storage that does not require immediate consistency. The nature of consistency means RDBMS are more complex when scaled, not that they don't scale. Saying RDBMS don't scale is just drinking the NoSQL CoolAid. NoSQL is easier to scale because it has no interest in immediate consistency. Add ACID requirements into the mix and NoSQL can't cope - but remember it does not need to as the problems it solves are different. One size certainly does not fit all, but always remember that an ACID compliant RDBMS can do all things NoSQL can do, but the opposite it not true. Your choice is all about overhead. On another point, let's stop using the term NoSQL and call it what it is - NoQL. Using the term NoSQL is marketing bias, not technical reality. PostgreSQL supported key/value stores whiles most NoSQL devs were in diapers. (See hstore) The problems of data stores that do not need SQL like interrogation or consistency is well understood *and* already solved – NoSQL is not new, but certain storage requirements (web distributed storage) makes them more relevant now.
The primary reason given for the whole array of NoSQL solutions (speed and no need for query languages) is secondary to the better reason – simple scaling of data storage that does not require immediate consistency. The nature of consistency means RDBMS are more complex when scaled, not that they don’t scale. Saying RDBMS don’t scale is just drinking the NoSQL CoolAid. NoSQL is easier to scale because it has no interest in immediate consistency. Add ACID requirements into the mix and NoSQL can’t cope – but remember it does not need to as the problems it solves are different.

One size certainly does not fit all, but always remember that an ACID compliant RDBMS can do all things NoSQL can do, but the opposite it not true. Your choice is all about overhead.

On another point, let’s stop using the term NoSQL and call it what it is – NoQL.
Using the term NoSQL is marketing bias, not technical reality.

]]> Comment on Big Data Analytics at Netflix. Interview with Christos Kalantzis and Jason Brown. by Brady Wetherington http://www.odbms.org/blog/2013/02/big-data-analytics-at-netflix-interview-with-christos-kalantzis-and-jason-brown/comment-page-1/#comment-7583 Brady Wetherington Mon, 25 Feb 2013 22:25:55 +0000 http://www.odbms.org/blog/?p=2004#comment-7583 Mongo is not without its flaws - they are numerous and substantial, and I have written about them extensively - but this is not an apples-to-apples comparison of architectures. If you want to scale writes, you use sharding. If you want to survive failures, you use replica sets. You could argue it's nicer to have nodes that run partitions of data which are replicated around on nodes (I certainly would) but the mongo architecture is very simple and very easy to administer. Mongo is not without its flaws – they are numerous and substantial, and I have written about them extensively – but this is not an apples-to-apples comparison of architectures.

If you want to scale writes, you use sharding. If you want to survive failures, you use replica sets. You could argue it’s nicer to have nodes that run partitions of data which are replicated around on nodes (I certainly would) but the mongo architecture is very simple and very easy to administer.

]]> Comment on Big Data Analytics at Netflix. Interview with Christos Kalantzis and Jason Brown. by Christos Kalantzis http://www.odbms.org/blog/2013/02/big-data-analytics-at-netflix-interview-with-christos-kalantzis-and-jason-brown/comment-page-1/#comment-7581 Christos Kalantzis Sun, 24 Feb 2013 21:12:14 +0000 http://www.odbms.org/blog/?p=2004#comment-7581 Hi Dwight, Let me preface this comment with a clarification, that the intention of the article was never to do a hatchet job on MongoDB. I am sharing our experiences with the technology and how it didn't fit into our use case of multi-datacenter, mutil-directional heavy writes. That being said, I'm glad you clarified that in today's MongoDB a master can be chosen automatically to fill that role and that a new master will then be chosen as needed, in case of failure. However, that is still a Master-Slave scenario, where ALL rights only go to the single Master (of that shard/replica-set) and eventually will get replicated to the Slaves. That architecture limits your write throughput to a single server. This subsequently limits the efficiency of your hardware usage, since adding more servers, doesn't increase both write and read throughput, unlike in C* where adding a new node to the cluster linearly increases both write and read throughput (<a href="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html" rel="nofollow">Reference</a>) <i>"A MongoDB replica set is a cluster of mongod instances that replicate amongst one another and ensure automated failover. Most replica sets consist of two or more mongod instances with at most one of these designated as the primary and the rest as secondary members. Clients direct all writes to the primary, while the secondary members replicate from the primary asynchronously. . . .If you’re familiar with other database systems, you may think about replica sets as a more sophisticated form of traditional master-slave replication. In master-slave replication, a master node accepts writes while one or more slave nodes replicate those write operations and thus maintain data sets identical to the master. For MongoDB deployments, the member that accepts write operations is the primary, and the replicating members are secondaries."</i> http://docs.mongodb.org/manual/core/replication/ Furthermore, setting up multi-directional mutil-datacenter replication, with MongoDB, is not supported under it's single master per shard/replica-set architecture. That was a very important use case for us and was a major reason for considering C*, which handles that scenario with <b>minimal operational complexity</b>. Cheers, Christos Hi Dwight,
Let me preface this comment with a clarification, that the intention of the article was never to do a hatchet job on MongoDB. I am sharing our experiences with the technology and how it didn’t fit into our use case of multi-datacenter, mutil-directional heavy writes.

That being said, I’m glad you clarified that in today’s MongoDB a master can be chosen automatically to fill that role and that a new master will then be chosen as needed, in case of failure.

However, that is still a Master-Slave scenario, where ALL rights only go to the single Master (of that shard/replica-set) and eventually will get replicated to the Slaves. That architecture limits your write throughput to a single server. This subsequently limits the efficiency of your hardware usage, since adding more servers, doesn’t increase both write and read throughput, unlike in C* where adding a new node to the cluster linearly increases both write and read throughput (Reference)

“A MongoDB replica set is a cluster of mongod instances that replicate amongst one another and ensure automated failover. Most replica sets consist of two or more mongod instances with at most one of these designated as the primary and the rest as secondary members. Clients direct all writes to the primary, while the secondary members replicate from the primary asynchronously. . . .If you’re familiar with other database systems, you may think about replica sets as a more sophisticated form of traditional master-slave replication. In master-slave replication, a master node accepts writes while one or more slave nodes replicate those write operations and thus maintain data sets identical to the master. For MongoDB deployments, the member that accepts write operations is the primary, and the replicating members are secondaries.”
http://docs.mongodb.org/manual/core/replication/

Furthermore, setting up multi-directional mutil-datacenter replication, with MongoDB, is not supported under it’s single master per shard/replica-set architecture. That was a very important use case for us and was a major reason for considering C*, which handles that scenario with minimal operational complexity.

Cheers,
Christos

]]> Comment on MySQL-State of the Union. Interview with Tomas Ulin. by Dave Segleau http://www.odbms.org/blog/2013/02/mysql-state-of-the-union-interview-with-tomas-ulin/comment-page-1/#comment-7579 Dave Segleau Fri, 22 Feb 2013 18:48:41 +0000 http://www.odbms.org/blog/?p=2007#comment-7579 Robert, The Oracle NoSQL Database and MySQL are complementary technologies and enable Oracle to offer a complete solution stack to its customers. For web applications well served by a relational database, users can rely on MySQL, with the option to use the NoSQL access to MySQL via memcached to speed up key value read and write operations. For applications primarily handling large amounts of horizontally distributed unstructured and/or evolving data, Oracle NoSQL Database is the way to go. Oracle NoSQL Database can be used standalone or in conjunction with Hadoop and the Oracle Database for complex queries. Regards, Dave Robert,

The Oracle NoSQL Database and MySQL are complementary technologies and enable Oracle to offer a complete solution stack to its customers. For web applications well served by a relational database, users can rely on MySQL, with the option to use the NoSQL access to MySQL via memcached to speed up key value read and write operations. For applications primarily handling large amounts of horizontally distributed unstructured and/or evolving data, Oracle NoSQL Database is the way to go. Oracle NoSQL Database can be used standalone or in conjunction with Hadoop and the Oracle Database for complex queries.

Regards,

Dave

]]>