3

A WebApp writes a stream of data coming over a network to disk as key/value pair and then reads & send it over network again after few milliseconds in 99% of case. In 1% of cases write/read can be few hours to days apart (really don't know).

Latency is strict "no" in the app and we have to serve 100% of customers therefore I am planning to put data into RAM and later read and send it over network and only write to disk if the data is not read from RAM within a certain prefixed interval.

What could be possible solution to this problem?

P.S - Memcached looks like a good solution for using RAM instead of disk but Can memcached read/write of disk after time_to_live?

I also looking at Couchbase but I don't want to write to disk in all cases as 99% write/read happens in the matter of milliseconds.

Is it possible that after time_to_die Memcached could write the key/value to Couchbase instead of removing it from RAM and read it on demand?

[Edit 1]

After spending last few trying to explore various options. The following looks like a possible solution

  1. Write the data stream simultaneously to the RAM (using Memcached) and disk using (GlusterFS).
  2. In case the data is demanded by the application layer check it first in the RAM (Memcached) if it return the data ok, if it does not check the data on disk GlusterFS.
  3. Remove data stream from RAM if data is demanded by application or when time_to_live is reached whichever is earlier.

Suggestion most welcome.

yannis
  • 39,547
  • 40
  • 183
  • 216
Gaurav Agarwal
  • 133
  • 7
  • 5
    most obvious solution would be to use a RAM-disk – ratchet freak Mar 27 '13 at 09:57
  • @ratchet freak how does a RAM-disk help? As far as I'm aware all a RAM-disk really does is provide a filesystem style wrapper around a block of memory which doesn't seem to solve the problem. – Mike Mar 27 '13 at 16:11
  • 3
    It helps because your question begins "A WebApp writes a stream of data coming over a network to disk." Switching from rotating or solid-state disks to a RAM disk may cut the latency to an acceptable value without having to rewrite your code. – Blrfl Mar 27 '13 at 18:37

4 Answers4

2

A lot of how you handle this problem is going to hinge on that requirement of 100% of the customers being served. When the goal is absolutely no downtime then performance will almost always have to take a second position to reliability.

You say that your timespan for a typical response is a matter of milliseconds but how do you want to handle the situation where an error occurs within this timeframe? It is easy to imagine a machine getting reset while it is waiting on a long process (say on the order of hours) but that reset could also happen directly in the middle of a transaction that would typically happen in a matter of milliseconds. Maybe the machine loses power at that exact moment or the RAM ends up corrupted.

If reliability is the key to your system then I would say that your only real option is to write the data to a safe storage location before you process it. If the data is not safely stored then it is not processed by the system.

The better solution would most likely be to lower your requirement form 100% to 99.9% or similar and then you could ignore situations like the aforementioned error within a typically fast process.

Mike
  • 2,046
  • 16
  • 18
  • +1, Machine reset can be taken care with data replication on two servers. I understand even than 100% reliability cannot be achieved but it can be close. Any solution suggestions? – Gaurav Agarwal Mar 27 '13 at 17:01
1

Remember that RAM is volatile and if the server has to reset then that data would be lost. This sounds like it would be a concern, as you say you have to serve 100% of customers.

I would recommend writing your own buffering system which keeps data in RAM but writes it to disk after a small delay. If the data is served within this time then there is no reason to write to disk, and the resources can be freed.

Remember to reload unsent data at start-up.

intrepidis
  • 111
  • 4
  • +1, can you think of how to go about writing such a distributed buffering system. Also any solution which can be close and can be immediately used. – Gaurav Agarwal Mar 27 '13 at 16:49
  • Also solution for server reset (get rid of RAM volatility) could be content replication in two servers. – Gaurav Agarwal Mar 27 '13 at 16:58
  • As Mike said, a more realistic 99.9% would mean you don't have to deal with those situations and therefore also content replication wouldn't have to be an issue. – intrepidis Mar 31 '13 at 23:30
1

Memcached is just a cache. The out of box java version at https://code.google.com/p/quickcached/ supports writing to disk on exit but for what you need, I think you will have to add your own code.

One thing to consider is how much of data, at peak load do you think you will have 3 years from today? If that is not too much can use your own RAM with a in memory cache like whirly, and your own thread that peeks in the to cache every 5 minutes and saves to disk items that are not yet picked up. Note: your POJO will have to have the checked in time, whirly wont tell you when an item was put into its cache.

tgkprog
  • 595
  • 6
  • 18
  • +1, What is the difference between Memcached and Whirly cache? – Gaurav Agarwal Mar 27 '13 at 19:00
  • Whirly is in your RAM, part of your JVM. A global hashmap that can be configured to drop old items and / or when the number of items is > X (not size or space in RAM But number of elements). Mem and quick cache are in their own JVM. Typically would have 2+ instances of quick cache, in our env we have them on separate boxes. Still have the over head of network access but a quick protocol. – tgkprog Mar 27 '13 at 20:11
  • I think the data need ca be heavy therefore I should go with distributed cache from the beginning. I have added a possible solution in the Edit to question. – Gaurav Agarwal Mar 28 '13 at 17:46
1

To put the things simple. Use Redis and you will never speak of memcache again. Following are some plus points:

First of all in Redis you get the option to persist data in the disk.

Second, you have data structures like list, set etc. Also, supports atomic operations.

gnat
  • 21,442
  • 29
  • 112
  • 288
vivek
  • 453
  • 1
  • 3
  • 16
  • Redis persistence can be a problem on AWS. See http://www.quora.com/Amazon-Web-Services/How-well-does-Redis-perform-on-AWS-in-2012. How does my solution in Edit looks? – Gaurav Agarwal Mar 28 '13 at 17:47