Just picked up this article on java.dzone.com Martin Fowler on ORM Hate. Fowler always has very interesting things to say due to his expertise in the industry.
There has been a lot of push-back against ORMs, especially in the NoSQL space and Fowler takes some time to talk about this. ORMs are a tool like any other and a lot depends on how we use them. One of the biggest complaints is that they are a big black box, which can be true, but they also are a HUGE help with relational mapping. Even manual SQL queries force you to do some sort of mapping operation since you are going from relational to object.
One trend I see is incorporating NoSQL support into various ORMs. Document stores seem to be popular for this, possibly because of the simplicity of the data model. The capabilities of each store however, very greatly, so this is difficult. Some stores like MongoDB and CouchDB provide support for more advanced queries, even SQL-like queries while other stores like Riak provide relatively limited support, essentially key-only access. Basho is working on adding more advanced support now with secondary keys and Riak Search.
- Craig
Friday, May 18, 2012
Thursday, May 10, 2012
Cell Architectures
Back to one of my favorite sites again. highscalability.com brings us a great article on Cell Architectures.
Cells are essentially a cluster of services that form some scalable part of the architecture. Cells are self-contained and can be swapped out as needed. Each cell will generally serve a specific portion of traffic. If a cell fails, then only a subset of users are affected.
My original thought of the size of a cell is much smaller than the examples give. For example, a cell may have a cluster of 50 or more servers. Obviously, these are larger companies that have large cells like this. Still, it's interesting to think about how cells could be put together on a smaller basis, depending on need.
From the article:
Enjoy!
- Craig
Cells are essentially a cluster of services that form some scalable part of the architecture. Cells are self-contained and can be swapped out as needed. Each cell will generally serve a specific portion of traffic. If a cell fails, then only a subset of users are affected.
My original thought of the size of a cell is much smaller than the examples give. For example, a cell may have a cluster of 50 or more servers. Obviously, these are larger companies that have large cells like this. Still, it's interesting to think about how cells could be put together on a smaller basis, depending on need.
From the article:
Cell Architectures have several advantages:
- Cells provide a unit of parallelization that can be adjusted to any size as the user base grows.
- Cell are added in an incremental fashion as more capacity is required.
- Cells isolate failures. One cell failure does not impact other cells.
- Cells provide isolation as the storage and application horsepower to process requests is independent of other cells.
- Cells enable nice capabilities like the ability to test upgrades, implement rolling upgrades, and test different versions of software.
- Cells can fail, be upgraded, and distributed across datacenters independent of other cells.
Enjoy!
- Craig
Subscribe to:
Posts (Atom)