One of the reasons we need to do complex joins and use referential integrity within the relational data model is to incorporate data sanity, prevent data redundancy, and enforce business domain contraints within the data layer. Use technologies like CouchDB, which offer much lighterweight solutions for your problem offering modeling techniques that suit your non-relational document oriented storage requirements like a charm. One of the ways to reduce the intellectual weight of your relational data model will be to take out elements that do not belong there. The user wants to view his latest portfolio statement, which has been stored in 10 different tables with complex indexed structures that need to be joined on the fly to generate the document. the problem is with the impedance mismatch between the business model and the data model. Now, the problem is not with the query per se. With an ultra normalized schema we try to fit in a data model that is not relational in nature, resulting in the complexities of big joins and aggregates while doing simple business queries. Or possibly, not in the form that today's relational model espouses. Traditionally we have been guilty of upsizing the database payload with logics, constraints and responsibilities that do not belong to the data layer. And when we talk about latency, it's not the latency of any isolated component, it's the latency of the entire architecture.Īn instance of an RDBMS is the single most dominant source of latency in any architecture today. It's a "latency arms race" out there, and the arbitrager with the least latency in their system wins. As Michael Stonebraker mentioned once, it boils down to one simple thing - latency. In order to increase the throughput of your application proportionately with your investment, you need to scale out, add redundancy and process asynchronously. I am not talking about scaling up, which implies adding more fuel to your already sizable database server. As long as you have a single database, there will be latency and you will have to accept it. With extra processing in the form of n actors pounding the cores of your CPU, the database will still be the bottleneck and SPOF. This can buy you some more donuts over and above your current throughput. In an earlier post, I had talked about scaling out the service layer of your application using actors and asynchronous processing. Rather than alternatives, the two technologies are complementary. Hence by writing data directly into Terracotta Network Attached Memory, data can be safely and durable stored, without risk of loss or corruption, and later drained to the DB asynchronously.Ĭan we conclude that for read-only (mostly) usecases, use memcached, while, for read-write usecases, use Terracotta to obtain transparent durability to the persistent store. Terracotta offers a truly coherent and clustered cache that remains consistent even in the presence of database writes through write behind to System of Record.You write into Terracotta Network Attached Memory and the data gets pushed into the database through asynchronous write behinds. In case of Terracotta it is the other way round. How do you handle database updates and prevent staleness of your memcached data ? Updates to data are usually handled by pushing writes to the database and then having some asynchronous processes (or database triggers) build objects that are pushed into memcached.Any algorithm for distribution, HA, failover is the responsibility of the client. Every memcached server is atomic and is not aware of any other memcached server in the cluster. This is quite a popular misconception that even Dare also mentions in one of his recent posts. Memcached is NOT a distributed hash table.In case you are trying to use it as a data store, think twice and refactor your thoughts. Memcached is a specialized engine for caching *only*.The following is a snapshot directly captured from the Twitter stream. ĭo you think Terracotta is an alternative to Memcached ? Here is a transcript of the chat, with some snippets of my own personal observations and conclusions. Ari was chatty and I thought it would be pretty useful to share his observations with a broader audience. It all started with Ari's initial observation regarding the confusion that exists in people's mind regarding the actual use of memcached and how it compares to Terracotta as a caching solution. Last week I was having a chatty tweeter session with Ari Zilka, CTO of Terracotta.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |