Continue Queries Limit Update Latency Unnecessarily!

38 views
Skip to first unread message

Joseph Moulton

unread,
Jun 19, 2019, 8:16:26 PM6/19/19
to RethinkDB
Ok Rethinkers,

After years of building websocket servers with the likes of Redis for lowest latency messaging and client-side app pub/sub updates, I am invested in building the next generation of cross-platform apps with the expressed purpose of supporting low latency updates via native asynchronous non-blocking, non-polling event mechanisms without the need for intermediate server services.  Among other reasons, most of them performance based pertaining to latency considerations, and without committing to building my own database service, I chose RethinkDB as NoSQL store of choice because of it's subscribe design implementation via changefeeds and built a native driver in pure C to support my native asynchronous multithreaded event based requirements with extensions to various platform languages (Obj-C, C++, Java).  Now that this is complete I can weigh in on some of the design choices apropos to REQL client-server communication and in particular one thing is making my stomach churn.  My primary question is this:

For query responses that return type SUCCESS_PARTIAL, why does RethinkDB require that the client send a CONTINUE query in order for the server to relase more information pertaining to the initial query?  There is no reason that having the server continue to send information should not be implicit.  If the client sends a query asking for a changefeed subscription or all of the data in a table of course I want the server to keep sending the client updates until I send a STOP message.  AFAICS, all this does is unnecessarily increase the overall latency to receive a changefeed update when one is ready by requiring the client to send a message all the way to the server before the server releases information to the client that it already has.  

Why? Why? Why?  I wish you hadn't done that.

Is the slack channel still open?  It seems there is no way to join?

Who would be the relevant person(s) to talk to responsible for v2.0+ design and how would I go about reaching them?

--Joe Moulton

 

Joseph Moulton

unread,
Jun 19, 2019, 8:46:49 PM6/19/19
to RethinkDB
I understand this was probably because designers wanted to prevent the server from sending information over the network to lost connections, but since the server is still holding onto those socket connections and query queues until it knows the connection is lost it doesn't really save significantly on server resources.

A couple [naive] solutions off the top of my head:
 
  1.  Connection Keepalive exchange.  Just like websockets.
  2.  Query Keepalive Exchange:  SUCCESS_PARTIAL responses could be interspersed with SUCCESS_PARTIAL_KEEPALIVE, which is when the Client CONTINUE query should be issued. 

Michael Lucy

unread,
Jun 20, 2019, 2:35:11 PM6/20/19
to reth...@googlegroups.com
Hi Joseph,

The reason the client needs to send a CONTINUE query is so that there is backpressure on the server.  If the client requests a stream of records and is consuming them more slowly than the server can produce them (which is surprisingly common), we need to make sure we aren't backing up millions of records in a queue somewhere.

CONTINUE queries shouldn't hurt performance if clients are written correctly.  The intended design is that clients fetch one batch ahead.  So you fetch batch 1, get it back, send a continue query to fetch batch 2 immediately, get it back, and then fetch batch 3 as soon as the client is done processing batch 1.  This allows you to process batch 2 while the CONTINUE query for batch 3 is being processed by the server.

As long as network latency is small compared to the amount of time it takes to generate a batch (which it should be if the batch sizes are correct), using CONTINUE queries with this pattern shouldn't introduce any unnecessary delays.

Best,
Michael

--
You received this message because you are subscribed to the Google Groups "RethinkDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rethinkdb+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rethinkdb/b479cd44-fb59-4aac-b290-6233c3d7c391%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Joseph Moulton

unread,
Jun 21, 2019, 12:36:14 PM6/21/19
to RethinkDB
To Michael,

Thanks for regurgitating how RethinkDB works and completely ignoring my concerns.  And thanks for intentionally spelling my name wrong even though I signed as "Joe" and you saw this.  How disrespectful.  

To everyone else in the world,

I am not satisfied with Michael's response.  I clearly anticipated exactly what he would say.  

1)  Under successful conditions, the server will ultimately need to queue those millions of records to be consumed by the client anyway.  So I'm ok with that.  One would just need a way to mitigate without dictating the performance of the success case.  I offered a solution to keep pressure minimized while more or less removing the demand to have the client ask for a continue update on every response.  I did this before Michael even responded.    

2)  Michael describes a serialized client consumption design, which espouses my concerns entirely.  The reason I [had to] build my own rethinkdb driver is because the official drivers are asychronous but NOT CONCURRENT, which means they do not lend to multithreaded and parallel processing design patterns.  If I request a query or a changefeed with a certain response size I want to process those responses concurrently as fast as the server can dish them out.  As the client, I shouldn't have to care if I've I received or finished processing any other responses associated with the query.   Anything else is just a waste of time and will never be as performant as a database service implementation that understand this.

If a client has to keep asking for changefeed updates then a true subscribe pattern it is not.   I didn't want to believe it until now, but it's no wonder RethinkDB is getting its ass kicked in this regard by relational implementations such as Postgres. 

Joe 
To unsubscribe from this group and stop receiving emails from it, send an email to reth...@googlegroups.com.

Joseph Moulton

unread,
Jun 21, 2019, 1:04:39 PM6/21/19
to RethinkDB
Actually, as an amendment to item 1.  I'm not sure why Michael is concerned with queueing the server responses for the client anyway.  That is a self imposed restriction.  If the server sends them as fast as it can generate them and doesn't rely on a client response to keep generating responses associated with the query (like it should) then it can let go of that memory as fast as the server can send them over the network to the client connection and doesn't need to worry about queuing for client side consumption.  

Sagiv Frankel

unread,
Jun 23, 2019, 5:01:28 AM6/23/19
to RethinkDB
Dude,

Seems pretty obvious your the one being disrespectful.

1) The guy took the time to answer your question - he's not paid for that. Doesn't matter if you like the answer or not.
2) Your title in the thread is Joseph, you might have taken offence with Joe for all we know.

Ω Alisson

unread,
Jun 23, 2019, 12:20:02 PM6/23/19
to reth...@googlegroups.com
Hey Joseph, besides you being completely ungrateful for a nice ex-RethinkDB answer, the database lost the race because of lack of funding, the development has been stale for three years.

To unsubscribe from this group and stop receiving emails from it, send an email to rethinkdb+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rethinkdb/29dee8a4-76fe-4b31-b877-69f7bf9a3c12%40googlegroups.com.

Joseph Moulton

unread,
Jun 23, 2019, 12:49:56 PM6/23/19
to RethinkDB
Under Sagiv’s logic we should all thank Donald Trump for lying to us or not being a smart enough diplomat to handle world policy and then thank him when he provides us unsatisfactory answers or lies to us because “he’s not paid for that.  Doesn’t matter if you like his answer or not.."  None of us get paid to post here, “Dude”.  We post here looking for actual substantive responses.  Note the distinct lack of substance in your response.

That being said, you are going to take offense, but because you are a web developer I could care less if you felt that you had anything of substance to say anyway.  As a web developer, you will never be qualified to provide any opinion or input relevant to this matter.  You wholly rely on frameworks developed by native developers for all the work you do.  I came here to get answers from those responsible for the native RethinkDB service implementation.   Given that you are a software developer who has spent 5+ years in the industry but has not taken the initiative to [at least start to] learn native development, I have no respect for you.  Given that you are an employee of WeWork, even if you were a native developer, your background and field wouldn’t impress me enough to give you a second thought.

Moreover, since an Israeli citizen has taken a demanding tone with me and taken the time to call me out, as an American citizen, I am going to use this as an opportunity to say I am sick of the demanding tone that the Israeli government has taken toward the US government over my lifetime and beyond in forcing us to take sides and action in your never-ending crusade against muslims over holy lands, which is not and never has or will be our prerogative.  We are helping you because we feel you have been persecuted.  For no other reason and that puts us in hot water with the rest of the world.  Why don’ t you have some respect for that?

This is not a problem specific to RethinkDB’s forum.  This type of laziness and pushback is indicative and inherent to the vast majority of personalities that become developers and thus frequent forums such as these.  Personalities like YOU and Michael.  I’m not going to apologize for being the one person that demands that these forums actually prove substantive and those who participate —especially the moderators—  stop showing laziness and don’t just give one off responses that don’t address genuine, substantive concerns so they can wipe their hands of a particular post and claim that they’ve responded to it.

Disrespect intended.

Joe

Joseph Moulton

unread,
Jun 23, 2019, 12:59:26 PM6/23/19
to RethinkDB
This is BS Alisson, 

Yes the initial company that pushed RethinkDB folded in 2015.  Then it changed hands to an opensource community, under which it is still very much alive.  It got its last update, 2.3.6, in late 2017 -- not 3 years ago.  Do you even think before you type?  How do you not know that?


But fine, I'll just take over RethinkDB service development myself and I won't share with any of you.

Ω Alisson

unread,
Jun 23, 2019, 2:09:02 PM6/23/19
to reth...@googlegroups.com
LOL, what a epic douchebag. Dude, I am one of the few developers you can ask about RethinkDB current status. If you think the project is "very much alive", no problem, all the power to you.

To unsubscribe from this group and stop receiving emails from it, send an email to rethinkdb+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rethinkdb/84b70862-425c-44f2-abec-cc0dda3cf794%40googlegroups.com.

Joseph Moulton

unread,
Jun 23, 2019, 2:29:25 PM6/23/19
to RethinkDB
Asking for work in a forum for a database service that you consider to be "defunct" and the same forum you call people "douchebag" is definitely the way to go for a woman in this field! :)

Good luck to you in your career!

Ω Alisson

unread,
Jun 23, 2019, 3:12:48 PM6/23/19
to reth...@googlegroups.com
Oh, I have no problem in calling you a douchebag, also no problem in helping people optimize their RethinkDB databases or migrate to something that has a brighter future, I'm not delusional.
My career is going well, thanks! :)

To unsubscribe from this group and stop receiving emails from it, send an email to rethinkdb+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rethinkdb/7669ad38-7367-46ae-beb6-89dffb139612%40googlegroups.com.

Jordan Husney

unread,
Jun 24, 2019, 8:39:04 PM6/24/19
to reth...@googlegroups.com

Does this group have a moderator? I welcome the activity, but I would also like a higher signal to noise ratio.



For more options, visit https://groups.google.com/d/optout.


--
Parabol
Jordan Husney | Co-founder & CEO 
Parabol | https://parabol.co

🔒 PGP Key
Reply all
Reply to author
Forward
0 new messages