<div dir="ltr"><div>O.T.</div><div><br></div>Hehe, that Aerospike review mentions that they claim 100% uptime (with seemingly undisclosed precision).<div><br></div><div>«This makes Aerospike’s uptime infinitely better than the Ericsson AXD301 switch, which delivered somewhere between five and nine nines of availability in a system comprised of 1.1 million lines of Erlang.»<br></div><div><br></div><div>(Never mind that the claim that 100% would be "infinitely better" than e.g. 99.999% is ludicrous in itself. I assume it was made tongue-in-cheek.)</div><div><br></div><div>Of course, this is ridiculous, as also the in-depth review demonstrates. Uptime figures are only useful in context, and comparing uptime claims of systems with different purposes is not particularly meaningful. For example, for the AXD 301, disturbance would be registered as downtime if one network interface (of potentially hundreds) was unable to process calls for 15 seconds (which is, BTW, what happened in the "9 nines" case: a restart of a single device board.) Is a database cluster still "up" if it stays responsive but has lost your data?</div><div><br></div><div>When claiming availability, you have to be very specific.</div><div><br></div><div>The article also mentions cluster sizes of "between 1 and 100 nodes". Guaranteeing 100% uptime in a 1-node 'cluster' is simply not possible.</div><div><br></div><div>Anyway, that article is two years old. Today, Aerospike claims "demonstrated uptime of five 9s". Still very good, but I guess "infinitely worse" than it used to be. ;-) (<a href="http://www.aerospike.com/benefits/high-availability/">http://www.aerospike.com/benefits/high-availability/</a>)</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div>PS This is not to defend the "9 nines" claim, which was never officially made by Ericsson. It was made in a press release by British Telecom. Ericsson doesn't divulge the actual uptime figures of its systems, but at least at one time it was ok to claim publicly that the average recorded field uptime of AXD 301 systems was "better than 5 nines".</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-19 1:00 GMT+02:00 Paul Oliver <span dir="ltr"><<a href="mailto:puzza007@gmail.com" target="_blank">puzza007@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'd recommend checking <a href="http://jepsen.io" target="_blank">jepsen.io</a> for testing of distributed systems. There's a very thorough review of Aerospike there with some results that may give you pause. <a href="https://aphyr.com/posts/324-jepsen-aerospike" target="_blank">https://aphyr.com/posts/324-<wbr>jepsen-aerospike</a></div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 19, 2017 at 4:54 AM Heinz N. Gies <<a href="mailto:heinz@licenser.net" target="_blank">heinz@licenser.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I would not give too much on those ‘benchmarks’, they’re highly bogus and that’s if you’re treating them kindly.<div><br></div><div><div>For a starter it uses default settings and they are not even provided. Redis is a in memory store by default, is it even saving the data? How are risk or Cassandra set up, unlike mongo or redis the others those are build to be clustered, are the default configs used for them disabling unless overhead? Does it mean risk, that is storing every write on disks, perhaps 3 times, is only 10x slower compared to a database that never writes to disk and only keeps one copy?</div><div><br></div><div>For you own sanity, print that benchmark, find a burn proof area (safety matters!) and set it on fire then move on and benchmark for yourself with a real use case and sensible data.</div></div></div><div style="word-wrap:break-word"><div><div><br><div><div><br><div><blockquote type="cite"><div>On 18. Sep 2017, at 17:34, code wiget <<a href="mailto:codewiget95@gmail.com" target="_blank">codewiget95@gmail.com</a>> wrote:</div><br class="m_5855177253793149425m_5978184477416526348Apple-interchange-newline"><div><div style="word-wrap:break-word">HI,<div><br></div><div>Thank you all for your replies.</div><div><br></div><div>Nathaniel: The reads must be 'eventually' consistent, at least within a second. The problem is that it updates user connection information, and they will be unable to connect if our read does not get information from the write. So if we update, the connection before the write is fully committed will fail. I suppose it is ok if they cannot connect and just have to reconnect, but ideally they should be able to connect every time.</div><div><br></div><div>So Riak seems like a great solution, but speed wise really worries me. We are trying to connect as many clients as possible per server, this is very important as it saves us money. If the reads take 2-3x as long, this could be very slow and bad. According to this article: <a href="https://github.com/citrusbyte/redis-comparison" target="_blank">https://github.com/<wbr>citrusbyte/redis-comparison</a>, Riak is up to 10x slower than Redis. This would really hurt our operations.</div><div><br></div><div>To those who commented redis-cluster, my problem with a cluster solution is that redis-cluster seemed to be in an experimental stage. It also has the problem where if all copies of a node die, then the cluster will lose all that data and it is up to the user to not lose that data. All of this has to be handled by the user, and this seems like it will get tedious when there are multiple nodes and all it would take is for one admin to mess it up.</div><div><br></div><div>So this is where Aerospike comes in. Reading about them on the web they come off as the perfect tool for a version of redis that is distributed: <a href="https://stackoverflow.com/questions/24482337/how-is-aerospike-different-from-other-key-value-nosql-databases" target="_blank">https://<wbr>stackoverflow.com/questions/<wbr>24482337/how-is-aerospike-<wbr>different-from-other-key-<wbr>value-nosql-databases</a> . But for some reason, they don’t get as much attention as redis</div><div><br></div><div>Does anyone have experience with Aerospike? For my application, it seems like a no brainer.</div><div><br></div><div>Thank you all again,</div><div><div><blockquote type="cite"><div>On Sep 15, 2017, at 2:02 PM, Nathaniel Waisbrot <<a href="mailto:nathaniel@waisbrot.net" target="_blank">nathaniel@waisbrot.net</a>> wrote:</div><br class="m_5855177253793149425m_5978184477416526348Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>Scatter-shot reply:</div><div><br></div><div>Since you're using Redis right now, have you considered Redis Cluster (<a href="https://redis.io/topics/cluster-tutorial" target="_blank">https://redis.io/topics/<wbr>cluster-tutorial</a>)?</div><div><br></div><div>I'm using Cassandra and don't feel that it's got a small community or slow pace of updates. There are a lot of NoSQL databases and they all have quite different tradeoffs which tends to fragment the community, so your expectations may be too high.</div><div><br></div><div>Riak, ElasticSearch, EtcD, MongoDB, etc. You have many (too many!) options. When you say "read speed and consistency" what sort of consistency are you looking for? Is eventual consistency good, or do you require that every read that takes place after a write gets the new data?</div><div><br></div><div><br></div><div><br></div><br><div><blockquote type="cite"><div>On Sep 15, 2017, at 12:43 PM, code wiget <<a href="mailto:codewiget95@gmail.com" target="_blank">codewiget95@gmail.com</a>> wrote:</div><br class="m_5855177253793149425m_5978184477416526348Apple-interchange-newline"><div><div style="word-wrap:break-word">Hello everyone,<div><br></div><div>I am at the point where I have many Erlang nodes, and I am going to have to move to a distributed database. Right now, I am using a basic setup: each Erlang node has a copy of the same Redis DB, and all of those DBs are slaves(non-writable copies) of a master. A big problem with this is obvious - If the db goes down, the node goes down. If the master goes down, the slaves won’t get updated, so I would like to move to a distributed db that all of my nodes can read/write to that can not/does not go down.</div><div><br></div><div>The nodes do ~50 reads per write, and are constantly reading, so read speed and consistency is my real concern. I believe this will be the node’s main speed factor.</div><div><br></div><div>Another thing is that all of my data is key/key/value , so it would mimic the structure of ID -> name -> “Fred”, ID->age->20, so I don’t need a SQL DB.</div><div><br></div><div>A big thing also is that I don’t need disc copies, as a I have a large backup store where the values are generated from.</div><div><br></div><div>I have looked at as many options as I can -></div><div><br></div><div>Voldemort : <a href="http://project-voldemort.com/" target="_blank">http://project-voldemort.<wbr>com/</a> </div><div>- looks perfect, but there are 0 resources on learning how to use it outside of their docs and no Erlang driver, which is huge because I would both have to learn how to write a c driver and everything about this just to get it to work. </div><div><br></div><div>Cassandra: <a href="http://cassandra.apache.org/" target="_blank">http://cassandra.<wbr>apache.org/</a></div><div>- looks good too, but apparently there is a small community and apparently isn’t updated often</div><div><br></div><div>Scalaris: <a href="https://github.com/scalaris-team/scalaris/blob/master/user-dev-guide/main.pdf" target="_blank">https://github.com/<wbr>scalaris-team/scalaris/blob/<wbr>master/user-dev-guide/main.pdf</a></div><div>- Looks very very cool, seems great, but there is 0 active community and their GitHub isn’t updated often. This is a distributed all in-memory database, written in Erlang.</div><div><br></div><div><br></div><div>So from my research, which consisted heavily of this blog:<a href="https://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores" target="_blank">https://www.metabrew.com/<wbr>article/anti-rdbms-a-list-of-<wbr>distributed-key-value-stores</a> , I have narrowed it down to these three.</div><div><br></div><div>BUT you are all the real experts and have built huge applications in Erlang, what do you use? What do you have experience in that performs well with Erlang nodes spread across multiple machines and possibly multiple data centers?</div><div><br></div><div>Thanks for your time.</div><div><br></div></div>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div></div>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></div></blockquote></div><br></div></div></div></div></div>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>