4 ms·

SET: 253232.12 requests per second GET: 2130875.50 requests per second The 10:1 throughput ratio for GET vs SET is interesting. Redis being in-memory, the r

• refenestrator 5y ago
  Raft involves waiting for fsync on a majority of nodes, so that's not too surprising. 'Typical' is a matter of what guarantees you want to give.
  • toolz 5y ago
    Typically people use raft for leader election which in turn can coordinate writes. I don't think the writes are being fsync'd in the raft logs here. At least I wouldn't expect that behavior.
    • alexchamberlain 5y ago
      Each write should be fsync'd to the WAL, right?
      • stingraycharles 5y ago
        Yes but those can happen at the convenience of the particular node, not necessarily as a globally chrckpointed fsync()
        • refenestrator 5y ago
          Then you're sacrificing consistency guarantees. If less than a majority have committed a write, it could be lost while the cluster still has a quorum up. Waiting to report success until a majority have committed allows you to make guarantees with a straight face.. "it will probably be committed in the near future" is not the same thing.
          • rubiquity 5y ago
            Not necessarily. As long as your quorums always overlap you can have weaker commit requirements. See the FPaxos paper and some of Heidi Howard’s blogs for more on this. https://fpaxos.github.io/ https://fpaxos.github.io/
            • jimsimmons 5y ago
              FPaxos requires commit quorum and subsequent promise request quorum to intersect. It doesn't bring any significant thruput benefits
              • rubiquity 5y ago
                I didn't say FPaxos brought throughput benefits. I pointed out that you can still have a correct implementation without requiring majority quorums. But since you brought it up, FPaxos can have both lower latency and higher throughput than MultiPaxos/Raft[0] ;) 0 - https://dl.acm.org/doi/pdf/10.1145/3299869.3319893 https://dl.acm.org/doi/pdf/10.1145/3299869.3319893
                • jimsimmons 5y ago
                  Great link. Need to look into what WPaxos is.
    • jimsimmons 5y ago
      You don't understand Raft. Quorum has to fsync for commit
      • rubiquity 5y ago
        It reads like you and GP are talking about two different things. You’re talking about Raft specifics and the GP seems to be talking about a Vertical Paxos like setup where Raft is used for configuration and the data path uses another replication algorithm such as Primary-Backup or Chain Replication.
        • jimsimmons 5y ago
          Hmmm that sorta makes sense I guess. Sorta because raft is a replication algorithm. If you don't use raft in datapath you don't get any of its guarantees
          • rubiquity 5y ago
            Most data paths don't need consensus for replication. You can implement ACID Transactions on top of many other replication algorithms for example. Ultimately the choice comes down to read/write ratios. Chain Replication has much better read throughout than Paxos and Raft.
            • jimsimmons 5y ago
              I see. What's the catch though. Sounds like free lunch. Is there some gotcha with partition tolerance?
              • rubiquity 5y ago
                It’s the case of 2F+1 versus F+1. Paxos/Raft offer fault tolerance where as other replication algorithms don’t. If you have a node failure in Primary-Backup or Chain for example you need to reconfigure before committing more writes. However in practice and certain environments reconfiguration can be faster than or the same as a leader failure in Paxos that requires running Phase 1 again.
    • skyde 5y ago
      For the raft algorithm to be correct Fsync is required on a majority of node otherwise you are technically not implementing Raft. The reason is that in Raft if a node acknowledges to the leader that it wrote something to the log it must not later accept a different write in the same log position. This mean if for some reason server rebooted with dirty buffered writes that could not be flushed in time. it’s supposed to forgot everything it know and rejoin the cluster using a brand new node id.
• inglor 5y ago
  Often reads of data already committed only need to hit one node but writes need to wait for a majority so they need to wait for multiple nodes to receive and acknowledge the write. I haven't checked the code though so I might be off.
• bob1029 5y ago
  > Is a 10:1 ratio typical for a storage backed distributed kv store? In a single-node system, the best way to increase your write throughput is to batch requests over small chunks of time. Ultimately, the amount of writes you can perform per unit time is either bounded by the underlying I/O sequential throughput, or the business constraints regarding maximum allowable request latency. In the most trivial case, you are writing a buffer containing the entire day's work to disk in 1 shot while everyone sleeps. Imagine how fast that could be. A distributed system has all of the same properties, but then you have to put this over a denominator that additionally factors in the number of nodes and the latency between all participants. A single node is always going to give you the most throughput when talking about 1 serial narrative of events wherein any degree of contention is expected.
• AlphaSite 5y ago
  I wonder how geode performs here.
• jandrewrogers 5y ago
  Comparisons of read/write ratios has to account for several differences in design and implementation. Representative benchmarks are difficult. Things that can make a difference: Databases have subtly different definitions of "durability", so they aren't always doing semantically equivalent operations. Write throughput sometimes scales with the number of clients and it is not possible to saturate the server with a single client due to limitations of the client protocol, so single client benchmarks are misleading. Some databases allow read and write operations to be pipelined; in these implementations it is possible for write performance to sometimes exceed read performance. For open source databases in particular, read and write throughput is significantly throttled by poor storage engine performance, so the ratio of read/write performance is almost arbitrary. That 3:1 ratio isn't a good heuristic because the absolute values in these cases could be much higher. A more optimal design would offer integer factor throughput improvements for both reading and writing, but it is difficult to estimate what the ratio "should" be on a given server absent a database engine that can really drive the hardware.
  • sitkack 5y ago
    It depends, yes but ... (not discounting any of the above). One sees a lot of 3:1 in practice due to the replication factor. If you have 3 copies of the data and the client can read from any node, you get 3x the read performance as having to have a quorum write on two out of three nodes. To the GP, for a rough swag of what is possible out of given hardware, a combination of FIO and ACT (measures IO latency under a fixed load) is a good start. https://fio.readthedocs.io/en/latest/fio_doc.html https://fio.readthedocs.io/en/latest/fio_doc.html https://github.com/aerospike/act https://github.com/aerospike/act