Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A content repository for your PHP application or CMS?


Published on

The idea for using content repositories (CR) instead of relying on lower level database frameworks is gaining steam with several new kids on block, typically relying on NoSQL data stores.

This talk will give an overview of the current state of the art amid several use cases (including ease of use, performance and flexibility) and architectures.

CR such as Midgard, Lily, and architectures based on HBase, CouchDB, MongoDB (NoSQL stores) incombination with Information retrieval layers will be highlighted, as well is components or libraries to be used from the PHP side.

A second part treats the emgerging standard PHPCR, a standard API based on JCR (JSR-283)


Published in: Technology
  • Sex in your area is here: ♥♥♥ ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ❶❶❶ ❶❶❶
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

A content repository for your PHP application or CMS?

  1. 1. A content repository for your PHP application or CMS? August 20, 2011 Sankt Augustin Paul Borgermans & Henri Bergius
  2. 2. About me● Active in open source / PHP community for a while – PHP based CMS solutions (mostly eZ Publish) – board member● Fancying : – Apache family of projects (mainly Solr) – NoSQL (Not only SQL) and scalable architectures – eZ Publish & CMS systems in general – Semantic aspects● Contact @paulborgermans
  3. 3. The PitchIn many cases of web basedapplications, a content repository isa better alternative for managingand serving content (as opposed to the lower level SQL stores)
  4. 4. ArchitectureTraditional integrated approach Decoupled approach Content Management System Web Application Framework Abstraction? CR CR Database
  5. 5. OK, but what is a content repository?
  6. 6. A content repository is a provider of ...● Storage – Flexibility in content modeling – Durability – Scalability / Performance● Services – Read/Write of content, versioning – Access control – Information retrieval – (Analytics) – (Semantics)
  7. 7. Flexibility● You want it to swallow anything● The less data design implications, the better● Run-time, scriptable schemas● Let it map to your data-model effortlessly – Mixing structured and un-structered data/blobs● From SQL to Object/Document oriented access – Much more natural for most application domains
  8. 8. Durability● ACID, damn you! Of course you want it to be safe .. But it might be a trade-off for performance● Implicit / Explicit versioning (when desired)
  9. 9. Performance / Scalability● Maybe not always a concern● But should not be your concern beyond checking that it is scalable!
  10. 10. Services● Versioning● Information retrieval – Rich, complex queries/fetches – Full-text search – References / Relations● Access control – Plug-in mechanisms desired – Mapping of domain specific rules (to the CR)● Analytics / Semantics – Plugins / Tools
  11. 11. Challenges● Standardisation in APIs – Main API is very proper to underlying systems – CMIS – PHPCR● Mobile – Content optimisation – Extra analytics (location, context) – Off-line use
  12. 12. A selection of possible engines to drive a CR (in NoSQL land)
  13. 13. CouchDB● Content modeling: Document oriented, schema free● API: RESTful, (PHP wrapper @koredn)● Scalability: distributed, master-master● Robustness: ACID compliant● Built-in full text search: no● Extra – Off-line use cases – Map / Reduce
  14. 14. MongoDB● Content modeling: Document oriented, schema free● API: binary protocol, PHP extension available● Scalability: Master-Slave, Sharding● Robustness: at a cost● Built-in full text search: no● Extra – Updates in place for fields – Rich (ugly?) query syntax
  15. 15. Hbase● Content modeling: Google big table clone, column oriented● API: Thrift, HTTP● Scalability: excellent● Robustness: Not entirely ACID, but still very good● Built-in full text search: no● Extra – Built in versioning – Swallows large blobs easily
  16. 16. Apache Solr● Not so much storage (but can be a caching storage layer too)● Very rich and powerful Information Retrieval Engine● API: HTTP, Java, several PHP wrappers● Scalability: very good, and getting even better*● Robustness – SolrCloud*● Extra: join-like queries* * Solr 4.0
  17. 17. Lily
  18. 18. Lily, “big data” content repository● Provides a very rich feature set● RESTful, Java API● Building on● Apache license
  19. 19. Over to Henri …