NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



cms: All content tagged as cms in NoSQL databases and polyglot persistence

structr: CMS on top of Neo4j

structr :

structr is a free, open-source CMS under the GPLv3, written in Java, based on the fantastic NoSQL graph database Neo4j.

By design, structr is modular, distributed and easy to use.

structr is not yet stable, so please be patient and look out for bugs and minor (or even major) pitfalls.

If my memory serves me right, Neo4j started as a library used internally for building content management systems.

Patrick Durusau

Original title and link: structr: CMS on top of Neo4j (NoSQL databases © myNoSQL)

The HBase+Solr CMS Lily Reaches 1.0

Lily, the only CMS built on top of HBase and using Solr as its search engine, has reached the 1.0 version.

Lily is dead serious about Scale. The Lily repository has been tested to scale beyond any common content repository technology out there, due to its inherently distributed architecture, providing economically affordable, robust, and high-performing data management services for any kind of enterprise application.

Outerthought has talked in the past about their technical choices:

Original title and link: The HBase+Solr CMS Lily Reaches 1.0 (NoSQL databases © myNoSQL)


HBase: Putting a CMS on Top of It

How Lily, a CMS from OuterThought, is using HBase as its storage:

Lily offers a content model on top of HBase, which we believe to be of value for many layman content application developers, in the sense that if offers slightly higher-level concepts to shape a datatier with: records and fields, a set of data types, link, multi-value and hierarchical fields, a flexible versioning scheme, schema validation. Beyond that, we took a couple of popular content exchange models and verified if a mapping from these into Lily would be possible: HTML, RDF, the CMIS model, NewsML. We found out that a useful mapping was possible, so we’re confident that a broad range of content applications can be build on top of Lily.

Original title and link for this post: HBase: Putting a CMS on Top (published on the NoSQL blog: myNoSQL)


NoSQL Databases and CMS or ECM or DMS

Purists will probably say I’m generalizing a bit (as there are some differences between CMS, ECM, DMS, etc.), but more and more people in the market start to think that these would make good usage of NoSQL databases:

DMS of the future will need to adopt NoSQL  :

  • because new systems are build for Internet : highly available documents is required feature, imagine a place where everybody can really write simultaneously – no locks-in.
  • If you request a specific document, you will get it and there is no difference here with RDBMS, noSQL is even more performant.
  • The “eventually consistent” will not really change anything, when you need a global view of the data (stats for example) you will get it “consistent”.
  • Backup of documents could be done easily – and you will fall in love with replication
  • Sharding is your friend for large distributed database of documents

☞ Why ECM & e-Archiving Solutions Should Adopt NoSQL

Definitely not the first one talking about the future of CMS NoSQL. The first system that comes to my mind when saying CMS and NoSQL is ☞ Lily:

Lily CMS architecture

NoSQL and The Future of CMS

Interesting to check if the set of requirements of a CMS represent a good fit for NoSQL solutions:

  1. Richly structured content types
  2. Unstructured binary objects
  3. Relationships / references / associations
  4. The ability to evolve content models over time (what I call “schema evolution”)
  5. Branch / merge (in the Source Code Management (SCM) sense of the term)
  6. Snapshot based versioning
  7. ACID transactions
  8. Scalability to large content sets
  9. Geographic distribution

The only requirement that doesn’t seem to be satisfied by most of the NoSQL is “ACID transactions”. But in case this could be translated into atomic and durable operations, I think most of the NoSQL solution will pass this test too.

The guys from Outerthought, builders of the Daisy CMS, have been publishing a lot recently about their decision to build the next generation CMS (Lily) on top of HBase. Below are the slides of their presentation: “Learning Lessons: Building a CMS on top of NoSQL technologies” from Berlin Buzzwords

Another resource useful to understand the needs behind a CMS is ☞ OuterThoughts’ technology choices.