‫What is going on, guys?
‫My name is Hossein and this video, I want to discuss whether databases should move to quick or not.
‫So I've already discussed that.
‫All right.
‫So Database's guys uses most of the databases, uses their own protocol for making communications.
‫Right.
‫So if you have a client that I want to connect to a database like a Postgres or Oracle or SQL Server,
‫already there is always most of the time 99 percent is a TCP connection.
‫And that database built their own protocol on par on top of TCP.
‫So they have this special headers and they have their special compression and they do their own thing.
‫I am not aware of a protocol for databases, a universal protocol.
‫Correct me, guys, if anyone, a database engineer there that there was any wrong.
‫There is actually a protocol.
‫The only protocol that I'm aware of was resp, and that's for retests, which is retests protocol,
‫something communication protocol, resp.
‫Our ISP.
‫I believe I might be wrong that might the other protocols so that that created kind of a chaos in the
‫database engineering community because there is no protocol like grb see with with web traffic or that
‫walji obviously doesn't be used for web traffic, but rest for what the traffic or HDB for web traffic
‫to be on is right.
‫To be very specific.
‫It is used for Web most of the time, right.
‫There's very elegantly designed a micro services.
‫Now we're seeing a movement that every service that can make it with another service use GOPAC because
‫it has kind of a schema ID as very well defined and but databases, guys, databases of raw databases.
‫There is there is no protocol fit for it yet.
‫Right.
‫Yet there are many problems with databases, especially when it comes to the Web.
‫What do you do if you spin up a Web application, the first thing you do?
‫Right.
‫And I'm talking about relational databases more.
‫And I think this applies to also know school databases, because what do you do?
‫Want to open up a framework or an API gateway ride that does a Web API gateway that essentially talks
‫to a back in database?
‫The idea is you spin up a pool of connections and every request that comes in a get request, you take
‫that request you reserve.
‫A connection from the pool, you execute the query and you return the connection back to the pool and
‫you might say.
‫Can't we just use one single connection for everybody?
‫Bad idea, guys, never do this.
‫You might get away with it.
‫The database will not yell at you, but there is a big problem with this.
‫What why?
‫Why is it?
‫Database's was designed in the 70s until this day to be a stateful.
‫What does that mean?
‫That means if I as a client, connect to a database, I am the only one sending stuff to it.
‫And probably one process will use one connection to send a query, a select star and insert a transaction.
‫That's one process, right?
‫It was designed to be the Singleton thing.
‫Right.
‫And I said it's been working fine forever.
‫Nobody anticipated this blowing up of Web applications where now you have simultaneous gets requests
‫or post requests coming, but now the Web servers actually responsible for making their way to the database.
‫Well, now, yes, you have a single process with a single connection to the database, but multiple
‫users are sending those requests.
‫So it's kind of acting like a proxy.
‫What does that mean?
‫That means if you use the single TCAP connection or debted this connection, here's what will happen
‫if I come in and ask for my pictures as I use and I'm authenticated and you're going to use the same
‫TCP connection, hoping you're going to hit the same server using let's say you are using OJARS and
‫someone else is asking for their pictures the same exact second.
‫And you hit that query, right.
‫And you executed that simultaneously.
‫Right.
‫So you cannot guarantee the response that comes back for is for which requester unless there is metadata
‫that I'm not aware of a metadata that is getting sent with the Skype connection.
‫Right.
‫So if you send a request from the same process, you can get my pictures.
‫And that's very, very bad.
‫That's why nobody does that.
‫Right, because the TCAP connection is is is there's no order per say to it.
‫Right.
‫Is you can send a request and the other request can go back.
‫And so it goes you're kind of using the same TCP connection to get the packets back.
‫So anything any problem with the ordering.
‫Right.
‫Can give you into a very bad state so you don't do this.
‫So what do you do instead?
‫Once you send a request to a single connection, you say, hey, don't touch this connection.
‫This connection is for this request and then you start using this pooling idea, a been up 20 connections.
‫And if you want to make a request, reserve a connection from the pool executer query, get it back
‫and then respond back.
‫Right.
‫So that's what we do.
‫We do pooling.
‫Right.
‫That being said.
‫You cannot trust this single connection, think.
‫I might be wrong that some delegates actually implement some sort of a safety right, but you cannot
‫trust it.
‫I'm not sure which to implement these safety things.
‫Right.
‫Just request.
‫And they are not out of order.
‫You did, because one request can get delayed.
‫One response can get delayed by a fraction of a millisecond.
‫And you can you have no idea what responses for which request.
‫Right.
‫That's why we have streams initiative, too.
‫Right.
‫That's why Initiative one, we block you from sending another request until the response comes back.
‫Why do we do that?
‫Because we don't know.
‫We don't know which request is for what.
‫Your response, which responses for each request is the same problem.
‫Right.
‫So we have had offline blocking because of that because to prevent this problem.
‫And now we invented a video, obviously beautiful design.
‫We have a stream.
‫So every request now you can use multiple.
‫Request on this NTSB connection, as long as you elegantly tag each request with a story middy.
‫Now.
‫We solve this problem on the web, but the database community says, wait a second, why is that?
‫Why are we still using this boiling garbage thing?
‫It's a general question.
‫I don't know.
‫I might be wrong.
‫I think we should bring streams to database connections to database protocols.
‫Don't you guys think it makes sense?
‫Right.
‫It just makes perfect sense, specially for the Web.
‫Oh, my God.
‫The performance we're going to get from this and obviously we cannot implement this to be to right databases
‫database.
‫People get really freaked out when you say it's beyond databases.
‫They don't like that couch killed that idea.
‫They were very brave and they implemented that because, you know, because of the extra here and I
‫understand the headers that is EDV to it doesn't really apply for databases and they are just an overkill.
‫But still, that's why both databases elegantly designed their own protocols.
‫But I think we have a good candidate.
‫And guys, quick, quick is a great protocol.
‫Those guys said don't say step two is great.
‫The stream is amazing.
‫How will we push this beautiful design at the lower level, at the network level?
‫So that's why Quick was born as a logical connection UDP.
‫Architecture that has dreams in it, so now as application which should be free, will just it will
‫be a thin layer that uses quick, right.
‫It just have all that stuff.
‫So a database could use quick.
‫Watch database we'll use quick first.
‫I'm just waiting desperately for that database that will be brave enough to use quick.
‫Quick has their own problem, though, UDP, the Internet doesn't like YouTube much, right?
‫And doesn't like DCP either.
‫But you get the ECB has its own problem with retransmission and controls, that the mistake that the
‫ECB did was implementing this as a low level.
‫To be honest, it should have been implemented by the application level right at the application layer
‫or maybe at a higher level, a little bit higher level.
‫And and we're going to take care of it.
‫But it's it was implemented as a lower level, so we were stuck with it.
‫Right.
‫And now when we tried to introduce streams with DCPI, we ran into the problem.
‫The famous problem with SGB, too, with TCP, which is I have many streams.
‫Right.
‫And one stream is shady and it's I don't know, one stinking packet is corrupted to stream one and stream
‫two is waiting because of the stinking packet.
‫Despite having no resemblance of commonness at all, they they have nothing in common.
‫They share only the same TCP connection, but they have to wait because of this thinking packet that
‫is bad and in stream one quick solves that and they logically separate.
‫How do you like this animation guys?
‫I don't, I don't know how to do editing in animation.
‫I'm going to get better at this, I promise.
‫But but you see the idea I just got done so every stream is completely independent of that.
‫How's that French independent?
‫Every stream is independent by itself and it's doing its own thing.
‫So now if that stream 10 has a bad beckert in it, we only retransmit right.
‫That packet in stream ten stream want to stream to stream three could just go normally and think of
‫streams just like as normal request.
‫I get requests.
‫No one returns the three.
‫You can simultaneously concurrently send all that stuff in.
‫So now.
‫Yeah I, I'm waiting for a database that implements quick at that level.
‫Right.
‫And now.
‫The observer can have one DCB connection that serves millions of users.
‫This might be, of course, we're going to run into problems where that there will be lots of conjecture,
‫congestion control over a single DGP connection, but that that will save us memory, guys.
‫That will save us round trip.
‫That will save us.
‫Processing of this overside, I think is a good idea.
‫What do you think?
‫What are the odds then, guys, if you build Web applications, have you run into this problem before
‫or do you just do a stateless architecture like some people do that they don't use pooling?
‫They say, hey, every request closes, an opening opens and closes its own DCB connection to the database?
‫That's a little bit of an overkill, but some people do that to be absolutely safe.
‫Still works then I see in the next one you guys stay out in.