WEBVTT 00:00.000 --> 00:07.000 Okay, so I'm Matthias. 00:07.000 --> 00:11.000 I work at Pincap, coding on TIDB. 00:11.000 --> 00:12.000 Let's see what's at it. 00:12.000 --> 00:15.000 How many nodes would TIDB, by the way? 00:15.000 --> 00:17.000 Okay, that's good. 00:17.000 --> 00:21.000 I'm going to talk a bit about my SQL vector as well as AI. 00:21.000 --> 00:23.000 What's all the boss around that? 00:23.000 --> 00:25.000 How does it work? 00:26.000 --> 00:29.000 So there's a lot of abbreviations and words 00:29.000 --> 00:31.000 into an LLM-Rag AI vector. 00:31.000 --> 00:33.000 How does all this connect? 00:33.000 --> 00:35.000 What can you get out of that? 00:35.000 --> 00:37.000 How does it work in my SQL, 00:37.000 --> 00:40.000 another mySQL compatible databases? 00:40.000 --> 00:45.000 So the first part is just the AI part more or less. 00:45.000 --> 00:49.000 And the second part will be mySQL focused. 00:49.000 --> 00:51.000 So we do have this LLM, 00:51.000 --> 00:53.000 we have semantic search, vector embedding, 00:53.000 --> 00:55.000 vector search, drag. 00:55.000 --> 00:57.000 So what is all this about? 00:57.000 --> 00:59.000 How can you actually use it? 00:59.000 --> 01:02.000 What can you make use of this? 01:02.000 --> 01:07.000 So let's start with just the large language model, the LLM. 01:07.000 --> 01:13.000 So it's AI, generated AI, the statistic model more or less. 01:13.000 --> 01:17.000 It's trained on massive amounts of data. 01:17.000 --> 01:21.000 It works, it takes some input and generates outputs. 01:21.000 --> 01:25.000 So that's where the generated AI comes from. 01:25.000 --> 01:27.000 Once it's trained, it's not up to date. 01:27.000 --> 01:33.000 So it's a static model more or less once released. 01:33.000 --> 01:37.000 It made me specific content because it's trained on specific data. 01:37.000 --> 01:41.000 But it also would never have access to your own content. 01:41.000 --> 01:46.000 For example, you might have an internal database or an internal knowledge base or something like that. 01:46.000 --> 01:50.000 That the LLM has no context. 01:50.000 --> 01:52.000 It's not aware of that. 01:52.000 --> 01:58.000 And it will also generate an answer even if it's not trained on that. 01:58.000 --> 02:02.000 So it might start hallucinating. 02:02.000 --> 02:06.000 So you knew what TIDB is. 02:06.000 --> 02:09.000 Here I downloaded an installed Olamma. 02:09.000 --> 02:13.000 And I run the smallest deep seek version. 02:13.000 --> 02:17.000 I think most of you have heard of the deep seek the last week, basically. 02:17.000 --> 02:19.000 And I asked, what is TIDB? 02:19.000 --> 02:21.000 And it starts quite good. 02:21.000 --> 02:25.000 It's a model that in memory data base, blah, blah, blah, 02:25.000 --> 02:27.000 PyMongo, Mongo library. 02:27.000 --> 02:31.000 No, that's not actually what it is. 02:31.000 --> 02:33.000 So let's go up a bit in the model size. 02:33.000 --> 02:39.000 So this is a distilled model with 1.5 billion per meter, I think. 02:39.000 --> 02:45.000 So let's try with the $7 billion per meter. 02:45.000 --> 02:49.000 And then it starts to answer in Chinese. 02:49.000 --> 02:51.000 And it's quite easy. 02:51.000 --> 02:54.000 So you can ask please reply in English. 02:54.000 --> 02:56.000 And then of course it will reply in English instead. 02:56.000 --> 03:01.000 And since it's likely bigger model and it's this reasoning AI, 03:01.000 --> 03:04.000 it starts to do some reasoning text, blah, blah, blah. 03:04.000 --> 03:07.000 And then it comes up with TIDB is an open source distributed database. 03:07.000 --> 03:11.000 blah, blah, blah, blah, blah, blah, low latency high throughput. 03:11.000 --> 03:14.000 And then it comes to, it's built on top of the bulk language, 03:14.000 --> 03:19.000 and it's rooted in runtime offering un-unified framework SQL 03:19.000 --> 03:22.000 and bulk-based operations. 03:22.000 --> 03:27.000 And how many using the bulk language here, or bulk-based operations? 03:27.000 --> 03:32.000 Well, I actually used the bulk this morning. 03:32.000 --> 03:39.000 So it actually runs bulk-based operations, 03:39.000 --> 03:43.000 because bulk is using TIDB. 03:43.000 --> 03:47.000 So I do think that's where the connection comes 03:47.000 --> 03:52.000 and through distilling and so that's the connection. 03:52.000 --> 03:58.000 But this still doesn't help in explaining what TIDB is. 03:59.000 --> 04:04.000 So we can go to an even bigger model. 04:04.000 --> 04:09.000 So a 32 billion parameters. 04:09.000 --> 04:11.000 That is really good, actually. 04:11.000 --> 04:14.000 And it's not just, that's a lot of reasoning text and so on. 04:14.000 --> 04:16.000 And then it starts to spew out. 04:16.000 --> 04:18.000 It's an open source distributed database, 04:18.000 --> 04:22.000 the sign-tandle-post, transactional and analytic work load 04:22.000 --> 04:24.000 efficiently. 04:24.000 --> 04:27.000 So it's a solution for large scale applications. 04:27.000 --> 04:31.000 And then it has much more about the different components and so on. 04:31.000 --> 04:36.000 So that would be more or less similar to just look out our website 04:36.000 --> 04:38.000 about TIDB. 04:38.000 --> 04:42.000 So it all depends on the model and the elements, 04:42.000 --> 04:46.000 but what I wanted to show you here is that it will start hallucinating 04:46.000 --> 04:48.000 if it doesn't have the context. 04:48.000 --> 04:50.000 If it doesn't know about it, it will still give you an answer. 04:50.000 --> 04:53.000 And it will sound fairly okay. 04:58.000 --> 05:01.000 So then the next tool in this toolbox of AI, 05:01.000 --> 05:04.000 and so on, that would be semantic search. 05:04.000 --> 05:08.000 And that is meaning that search what I mean, 05:08.000 --> 05:11.000 not literally what I say. 05:11.000 --> 05:14.000 So by literally, then you can use a full text search. 05:14.000 --> 05:18.000 If you want search for anything that mentions automobile, 05:18.000 --> 05:22.000 then you can search for automobile and map that. 05:22.000 --> 05:25.000 But often, if someone says automobile, you probably 05:26.000 --> 05:28.000 mean a car, right? 05:28.000 --> 05:33.000 So the semantic search is to take the context 05:33.000 --> 05:37.000 or the mere kind of meaning of your question 05:37.000 --> 05:41.000 and answer that with something that relates to this. 05:41.000 --> 05:45.000 So not just word for word matching. 05:45.000 --> 05:50.000 And how that works is it's usually taking 05:50.000 --> 05:55.000 a multi-dimension vector to represent the meaning 05:55.000 --> 06:01.000 or something that relates to your object that might be text, 06:01.000 --> 06:06.000 but even the image or some other kind of object. 06:06.000 --> 06:11.000 And the important part here is that it uses tailored models 06:11.000 --> 06:14.000 for generating these vectors. 06:14.000 --> 06:18.000 So depending on your area for search and so on, 06:18.000 --> 06:21.000 it's a model that is used that will say, 06:21.000 --> 06:26.000 if it's a good match or not. 06:26.000 --> 06:28.000 And then from those models, 06:28.000 --> 06:32.000 that's where all these vector and vector embeddings comes from. 06:32.000 --> 06:39.000 So vectors, just stored even like in reference table 06:39.000 --> 06:43.000 or a specific vector database or anything like that, 06:43.000 --> 06:46.000 but it can have a foreign key or whatever, 06:46.000 --> 06:48.000 to your actually content. 06:48.000 --> 06:54.000 So you're embedding these generated vectors with the actual object. 06:54.000 --> 06:58.000 And that's how you use for doing the semantic search. 06:58.000 --> 07:00.000 So you have some other kind. 07:00.000 --> 07:02.000 You can have a question. 07:02.000 --> 07:06.000 You want to say, can you find the image similar to this? 07:06.000 --> 07:09.000 Then you would actually create these embedded vectors 07:09.000 --> 07:11.000 through the tail or model, 07:11.000 --> 07:14.000 and then you would compare these vectors. 07:14.000 --> 07:17.000 So the result of the vectors, 07:17.000 --> 07:21.000 if they are closed by some kind of distance, 07:21.000 --> 07:27.000 it would mean that they semantically are similar. 07:27.000 --> 07:32.000 And these vectors, they can have thousands of the dimensions. 07:32.000 --> 07:35.000 So it's not just a single number. 07:35.000 --> 07:41.000 It's quite a lot of data for each and every of these vector embeddings. 07:42.000 --> 07:44.000 This is how it would look. 07:44.000 --> 07:46.000 If you use a MySQL client, 07:46.000 --> 07:48.000 just connecting to TIDB, 07:48.000 --> 07:50.000 it's similar in the other ones. 07:50.000 --> 07:54.000 One particular thing with TIDB is it actually 07:54.000 --> 07:59.000 implicitly converts from a text string containing vectors 07:59.000 --> 08:01.000 directly to a vector of back and forth. 08:01.000 --> 08:04.000 So you don't need to have the translation function. 08:04.000 --> 08:07.000 I will come back to that in the second part of the talk. 08:08.000 --> 08:11.000 So here you can just insert vectors, 08:11.000 --> 08:15.000 and then you can do a search for the vectors. 08:15.000 --> 08:20.000 And here is the important part that you order by the vector distance. 08:20.000 --> 08:26.000 So that would mean that the closest one with shortest distance 08:26.000 --> 08:32.000 would be more similar than the one with a bigger distance. 08:32.000 --> 08:38.000 And that's what we would be called vector search, 08:38.000 --> 08:41.000 finding the closest neighbor vector. 08:41.000 --> 08:43.000 And for small data sets, 08:43.000 --> 08:46.000 then it's perfectly fine to do a brute force. 08:46.000 --> 08:47.000 Computers are super fast. 08:47.000 --> 08:50.000 You can run millions of computation. 08:50.000 --> 08:53.000 And this is simple data actually. 08:53.000 --> 08:56.000 So you can even have the vectorized computation 08:56.000 --> 09:00.000 with the single-instrict multiple data instructions and so on. 09:00.000 --> 09:03.000 But when it comes to larger data sets, 09:03.000 --> 09:07.000 then of course it's thought to be inefficient and take long time 09:07.000 --> 09:08.000 and be expensive. 09:08.000 --> 09:12.000 So that's where an vector index comes into place. 09:12.000 --> 09:16.000 And from a database perspective, 09:16.000 --> 09:19.000 to me it was really weird when I started to play with that. 09:19.000 --> 09:21.000 Because without an index, 09:21.000 --> 09:23.000 I would have the exact order. 09:23.000 --> 09:27.000 I would have the 10 closest one as they were. 09:27.000 --> 09:33.000 But adding an index, I might get just miss one that was closer 09:33.000 --> 09:36.000 or get one that was not as close. 09:36.000 --> 09:40.000 So it's an approximate indexing, 09:40.000 --> 09:45.000 which again in databases for me that work with database. 09:45.000 --> 09:48.000 It needs to be exact, it needs to be transactional. 09:48.000 --> 09:51.000 Otherwise we're doing something wrong. 09:51.000 --> 09:54.000 And here we're doing it approximately. 09:54.000 --> 10:04.000 So it's actually kind of okay, but it's not exact. 10:04.000 --> 10:09.000 This is just a way of running a plane. 10:09.000 --> 10:12.000 Again, tightly-bears an example. 10:12.000 --> 10:15.000 The last line you can see that the access 10:15.000 --> 10:18.000 or the activity is actually an index. 10:18.000 --> 10:23.000 And further under the operating operator in for you can see 10:23.000 --> 10:26.000 that it actually has an A and an index. 10:26.000 --> 10:29.000 So approximate nearest neighbor index. 10:29.000 --> 10:36.000 And that's what it would be using. 10:36.000 --> 10:40.000 And then now when we have these different concepts, 10:40.000 --> 10:42.000 how do we put that all together? 10:42.000 --> 10:46.000 So we have an LLM that will generate an answer. 10:46.000 --> 10:51.000 We have documents that we connected vectors to. 10:51.000 --> 10:56.000 We have models that match these objects to vectors. 10:56.000 --> 11:00.000 And we have the vector search for finding the closest ones. 11:00.000 --> 11:06.000 So those that would be similar as similar as possible. 11:06.000 --> 11:12.000 And then we can use the result for finding these similar objects. 11:12.000 --> 11:15.000 And we can feed that back to the LLM as context 11:15.000 --> 11:20.000 because it might not know anything about the question or the area you had. 11:20.000 --> 11:25.000 And by adding these context, the LLM can actually give you an answer 11:25.000 --> 11:31.000 with your private information about your company's 11:31.000 --> 11:33.000 sensitive documentation. 11:33.000 --> 11:35.000 That's just used internally and so on. 11:35.000 --> 11:39.000 And it can actually give you a well formulated answer 11:39.000 --> 11:44.000 about knowledge that you have that the LLM model did not have. 11:44.000 --> 11:49.000 So that's what called retrieval augmented generation. 11:49.000 --> 11:54.000 And visually you can say that you have a user query 11:54.000 --> 11:59.000 to start with and you want the nice formulated answer. 11:59.000 --> 12:04.000 You create a new vector from the query. 12:04.000 --> 12:08.000 So you have some kind of representation for what the query 12:08.000 --> 12:11.000 semantically would mean. 12:11.000 --> 12:14.000 And you want to search the database, 12:14.000 --> 12:17.000 but the database needs to be populated, of course. 12:17.000 --> 12:22.000 So that's a big area of what a lot of people in AI 12:22.000 --> 12:28.000 does now that how can you take documents or whatever you have 12:28.000 --> 12:30.000 and search for them. 12:30.000 --> 12:37.000 So you have different models for generating these embedded vectors. 12:37.000 --> 12:41.000 Usually if you have a big document and just creates a vector out 12:41.000 --> 12:46.000 of a big document, the matching will be quite poor. 12:46.000 --> 12:52.000 So this is a big area in a lot of trial and error for their specific context 12:52.000 --> 12:53.000 and so on. 12:53.000 --> 12:58.000 But the overall picture looks like this that you have your own data 12:58.000 --> 13:03.000 and you create embeddings for that so you can search and match for the query. 13:03.000 --> 13:08.000 And then the better matches you're feeding that back to the LLM. 13:08.000 --> 13:14.000 And it's as easy actually in the end as what can be called as prompt 13:14.000 --> 13:15.000 and you nearing as well. 13:15.000 --> 13:20.000 So instead of just sending the user query directly to the LLM, 13:20.000 --> 13:24.000 you will end up sending the user query to the LLM as 13:24.000 --> 13:28.000 please answer this query and then you just quote the query. 13:28.000 --> 13:33.000 Based on the context of these documents or these snippets that you got 13:33.000 --> 13:38.000 from the vector search, the similarity search. 13:38.000 --> 13:41.000 And then you push that to the LLM, 13:41.000 --> 13:47.000 and it can generate really nice answer with context from your data. 13:47.000 --> 13:54.000 That the LLM was completely unaware of. 13:54.000 --> 13:56.000 So that's the whole AI part. 13:56.000 --> 14:00.000 I will not go into deep depth and so on more about that. 14:00.000 --> 14:05.000 Then we come to the other part what's implemented in my SQL 14:05.000 --> 14:08.000 and my SQL compatible data basis. 14:09.000 --> 14:12.000 It basically needs two things. 14:12.000 --> 14:15.000 It needs to be able to store the vector, 14:15.000 --> 14:20.000 and it needs to calculate distances between the vectors. 14:20.000 --> 14:25.000 That's all the functionality you're actually requiring from the database. 14:25.000 --> 14:31.000 And there's a lot of specific vector databases and so on. 14:31.000 --> 14:33.000 But if you already have a database, 14:33.000 --> 14:40.000 why wouldn't you be able to serve this from your already existing databases? 14:40.000 --> 14:43.000 So the vector data type, 14:43.000 --> 14:47.000 that's introduced in my SQL 9, I think. 14:47.000 --> 14:51.000 MariaDB has that in 117, I think, 14:51.000 --> 14:54.000 tied to be added in 8, 3. 14:54.000 --> 14:56.000 I think, or something like that, 8, 4. 14:56.000 --> 15:00.000 It's released in LTS version, at least. 15:00.000 --> 15:03.000 It's normally a fixed number of dimensions. 15:03.000 --> 15:12.000 It can be now all implementation I've seen is a vector of 32 bit floats. 15:12.000 --> 15:15.000 It's only useful as a whole vector. 15:15.000 --> 15:19.000 You never use the individual values or anything like that. 15:19.000 --> 15:26.000 And it's specific to the model you generated it from. 15:26.000 --> 15:30.000 So you need to parse it when you're inserting. 15:30.000 --> 15:36.000 And this will be coming back in the rest of the pages, 15:36.000 --> 15:42.000 because there's so many different function names for the same thing. 15:42.000 --> 15:46.000 So I will ask around that. 15:46.000 --> 15:48.000 The type to be can do it implicitly. 15:48.000 --> 15:51.000 It can see, okay, this is probably a vector from your string. 15:51.000 --> 15:54.000 Otherwise, you need to specify that this is the string. 15:54.000 --> 15:57.000 It's a vector, use it as a vector. 15:57.000 --> 16:01.000 You can even, in one, in the different implementation, 16:01.000 --> 16:08.000 maybe use hexadecimal directly or even binary. 16:08.000 --> 16:12.000 Getting it out, if you've got select where you have a vector column, 16:12.000 --> 16:16.000 it might not be quite useful to do that in most places, 16:16.000 --> 16:19.000 because you have a thousands of vectors. 16:19.000 --> 16:23.000 So for application and so on, of course, it makes sense. 16:23.000 --> 16:26.000 But as a user, it's more as useless. 16:26.000 --> 16:31.000 So it might spew out just binary data or hexadecimal data 16:31.000 --> 16:34.000 or already parsed as the string again. 16:34.000 --> 16:39.000 And as you see, a lot of different ways to convert, 16:39.000 --> 16:41.000 or that different function. 16:41.000 --> 16:44.000 The weird part is why was not just cost used. 16:44.000 --> 16:47.000 It's a simple data type. 16:47.000 --> 16:52.000 There's not a specific way to get to form a vector like 16:52.000 --> 16:54.000 in your medical. 16:54.000 --> 16:56.000 So that was a bit weird. 16:56.000 --> 16:59.000 Is that something that really should be standing for it? 16:59.000 --> 17:01.000 There's no as well, standard, yes. 17:01.000 --> 17:04.000 Yeah, but if it was, yeah, it was simply simplified things for everyone. 17:04.000 --> 17:08.000 Yeah, I actually saw the TIDD actually have the implemented cost. 17:08.000 --> 17:13.000 But it's not documented for, I think. 17:13.000 --> 17:15.000 And then this is a core part. 17:15.000 --> 17:19.000 You want to have a way of getting the distance. 17:19.000 --> 17:23.000 Several ways of calculated distance and for vectors, 17:23.000 --> 17:27.000 the two main parts, the ways is the cost in the distance, 17:27.000 --> 17:31.000 would more or less say which angle would be between this, 17:31.000 --> 17:35.000 if you can think of an angle in multi-dimension world. 17:35.000 --> 17:41.000 Or you could even that would be a straight distance from one point to another. 17:41.000 --> 17:43.000 There's a few others as well. 17:43.000 --> 17:46.000 And then yet again, what function? 17:46.000 --> 17:51.000 And what would distance mean without which type of distance, 17:51.000 --> 17:53.000 would that mean? 17:53.000 --> 17:56.000 It's a late thing in MariaDB, for example, 17:56.000 --> 18:00.000 that will use whatever distance the first in vector indexes. 18:00.000 --> 18:05.000 So it's a nice thing, maybe, but it also doesn't. 18:05.000 --> 18:08.000 It can fool you as well, I think. 18:08.000 --> 18:11.000 And did you only look at Maria, TIDDD? 18:11.000 --> 18:13.000 I'll come back to that. 18:14.000 --> 18:20.000 And then there's some vector utility functions for dimension or length of a vector, for example. 18:20.000 --> 18:24.000 And then the core of it, can you speed it up? 18:24.000 --> 18:26.000 Do you actually have a vector index? 18:26.000 --> 18:29.000 Is the vector index transactional? 18:29.000 --> 18:32.000 So you can see it within your current transaction. 18:32.000 --> 18:36.000 Is it maybe a synchronous, so it will try to follow, 18:36.000 --> 18:41.000 but not have the very, very latest and definitely not your current transaction? 18:42.000 --> 18:46.000 Where is it just manually updated? 18:46.000 --> 18:50.000 Can you configure it more than your type? 18:50.000 --> 18:55.000 And then again, a big different syntax. 18:55.000 --> 19:00.000 For creating a vector, I don't think that the syntax is as important as being more compatible 19:00.000 --> 19:03.000 on actually using that in the column. 19:03.000 --> 19:06.000 So that's not an issue, I think. 19:06.000 --> 19:09.000 The different databases, MySQL by default. 19:09.000 --> 19:12.000 It's in 9-0 and forward. 19:12.000 --> 19:14.000 It has the vector data type. 19:14.000 --> 19:20.000 You can specify it just a vector or vector with a number of dimension. 19:20.000 --> 19:23.000 If you don't say anything, it will be by default, 19:23.000 --> 19:26.000 20,000 dimension. 19:26.000 --> 19:29.000 The weird part here is it treats it's like a worker. 19:29.000 --> 19:33.000 So you can have up to that number of dimensions. 19:34.000 --> 19:40.000 We doesn't really make sense because you would have a normally fixed model 19:40.000 --> 19:46.000 that has a fixed set of dimensions, 19:46.000 --> 19:49.000 but you can still insert fewer dimensions. 19:49.000 --> 19:52.000 There's not an error warning for that. 19:52.000 --> 19:55.000 So that might be something you can take back. 19:56.000 --> 19:59.000 One set of function names. 19:59.000 --> 20:03.000 But then you can't actually have a distance. 20:03.000 --> 20:05.000 They document it clearly. 20:05.000 --> 20:07.000 There's a distance function. 20:07.000 --> 20:09.000 And then you read the fine print. 20:09.000 --> 20:12.000 You don't have the distance function in the community edition. 20:12.000 --> 20:15.000 You don't have that in enterprise edition. 20:15.000 --> 20:17.000 You have that in heatwave. 20:17.000 --> 20:22.000 I'm not speaking about that here. 20:22.000 --> 20:25.000 That also means you have no vector index. 20:25.000 --> 20:31.000 So you can only store and retrieve the vectors in my SQL. 20:31.000 --> 20:35.000 But then next session we'll talk about my vector. 20:35.000 --> 20:37.000 So we'll just touch upon that likely here. 20:37.000 --> 20:42.000 It kind of adds the missing stuff for a standard my SQL. 20:42.000 --> 20:44.000 It's actually really easy to build and so on. 20:44.000 --> 20:47.000 But I'll leave that to them. 20:47.000 --> 20:49.000 That is your introduction to it. 20:49.000 --> 20:51.000 It uses the audit plugin. 20:51.000 --> 20:54.000 He query, right? 20:54.000 --> 20:56.000 Ten. 20:56.000 --> 21:01.000 And yes, that's fine. 21:01.000 --> 21:05.000 I like that. 21:05.000 --> 21:08.000 It's an in memory index, I think. 21:08.000 --> 21:12.000 They add the distance function as you see. 21:12.000 --> 21:16.000 And they have a different way of searching. 21:16.000 --> 21:22.000 And I'll leave that to the next presentation instead. 21:22.000 --> 21:26.000 Then you have a MariaDB 11. 21:26.000 --> 21:34.000 They only allow you to specify the vector data type with a specific number of dimensions. 21:34.000 --> 21:36.000 We kind of make sense actually. 21:36.000 --> 21:41.000 They have their own sets of function names. 21:41.000 --> 21:44.000 We have a vector distance without type. 21:44.000 --> 21:46.000 That's nice. 21:46.000 --> 21:49.000 But is it helpful or not? 21:49.000 --> 21:52.000 That's actually an 8118, I think. 21:52.000 --> 21:55.000 They do a vector index. 21:55.000 --> 21:57.000 The implementation of that. 21:57.000 --> 22:00.000 It's an Indian independence. 22:00.000 --> 22:07.000 But they only support my in a DB for now. 22:07.000 --> 22:12.000 And if you do need a MySQL compatible database. 22:12.000 --> 22:15.000 And MariaDB would be similar. 22:15.000 --> 22:20.000 And it will support vector index. 22:20.000 --> 22:22.000 And then type DB. 22:22.000 --> 22:24.000 That's open source. 22:24.000 --> 22:26.000 The scalable database and so on. 22:26.000 --> 22:29.000 It also supports the vector data type. 22:29.000 --> 22:34.000 Either you can set the fixed number of dimension. 22:34.000 --> 22:37.000 Or you can have it unspecified. 22:37.000 --> 22:40.000 It can be useful if you just want to store different ones. 22:40.000 --> 22:44.000 And per row, you would say, which type of model. 22:44.000 --> 22:45.000 And so on. 22:45.000 --> 22:50.000 So in some use cases, it's possible at least. 22:50.000 --> 22:55.000 It supports implicit conversion from text to vectors back and forth. 22:55.000 --> 22:59.000 So it's a bit nice to use by the command liners. 22:59.000 --> 23:02.000 But that's a bit different. 23:02.000 --> 23:07.000 And more or less always an application that would do uses. 23:07.000 --> 23:11.000 It has own sets of function names again. 23:11.000 --> 23:13.000 And it has some other things. 23:13.000 --> 23:16.000 You can actually use comparison directly on vectors. 23:16.000 --> 23:18.000 And do some arithmetics. 23:18.000 --> 23:20.000 And so on that as well. 23:20.000 --> 23:23.000 So you can do that. 23:23.000 --> 23:28.000 If you have those kind of needs for the AI and rate of AI. 23:28.000 --> 23:30.000 And that probably not as useful. 23:30.000 --> 23:32.000 But that's something that was implemented. 23:32.000 --> 23:34.000 Maybe for testing with uncle that. 23:34.000 --> 23:38.000 But it exists at least there. 23:38.000 --> 23:41.000 And then I do have a bit of cost here. 23:41.000 --> 23:42.000 And I'm not sure. 23:42.000 --> 23:46.000 Are there anyone from MariaDB here? 23:46.000 --> 23:47.000 OK. 23:47.000 --> 23:50.000 Then I can also directly at least to my SQL. 23:50.000 --> 23:57.000 Can we please, please, just agree on the function names and so on? 23:57.000 --> 24:01.000 But what about a postgrace or DB2 or a SQL server? 24:01.000 --> 24:02.000 And thank you for joining us. 24:02.000 --> 24:03.000 Yeah. 24:03.000 --> 24:05.000 I did a quick check. 24:05.000 --> 24:07.000 The vector distance. 24:07.000 --> 24:12.000 That's also what Oracle supports and SQL server supports. 24:12.000 --> 24:19.000 I think that the master on it will provide its vector distance and distance on both. 24:19.000 --> 24:22.000 Is it actually a vector distance? 24:22.000 --> 24:23.000 Oh, yeah. 24:23.000 --> 24:24.000 I couldn't use it. 24:24.000 --> 24:25.000 I can try it. 24:25.000 --> 24:26.000 OK. 24:26.000 --> 24:29.000 It was vector distance first. 24:29.000 --> 24:32.000 Can they make it to distance? 24:32.000 --> 24:33.000 Yeah. 24:33.000 --> 24:34.000 Yeah. 24:34.000 --> 24:38.000 But since I didn't talk about open source software here, I couldn't use it. 24:38.000 --> 24:40.000 Yeah. 24:40.000 --> 24:47.000 And then why not just use cost for costing back and forth because it's quite. 24:47.000 --> 24:50.000 Then I'm open for questions. 24:50.000 --> 24:52.000 Yes? 24:52.000 --> 24:57.000 So which type of index are you using a type of DB2? 24:57.000 --> 24:58.000 Yes. 24:58.000 --> 25:05.000 I think both type of DB and my vector is all using HS announced. 25:05.000 --> 25:10.000 So here I'll get some small world navigatable. 25:10.000 --> 25:15.000 And so I tried it to do the method play with it. 25:15.000 --> 25:20.000 But it stores also the full index and the full vector index. 25:20.000 --> 25:21.000 Yeah. 25:21.000 --> 25:24.000 And do that or are you able to not do that? 25:24.000 --> 25:30.000 Because at the end of my index as big as it is even bigger than my data, right? 25:30.000 --> 25:33.000 So as a DB8 like you actually like that. 25:33.000 --> 25:34.000 Yeah. 25:34.000 --> 25:35.000 No. 25:35.000 --> 25:36.000 That's something I'm more or less. 25:36.000 --> 25:40.000 Well, it depends because normally you're not storing the full index. 25:40.000 --> 25:49.000 You're actually storing like you're going down to, I think, MariaDB does in 16 or in 10 or something like that. 25:49.000 --> 25:53.000 So you're compressing the data a bit as well. 25:53.000 --> 26:00.000 I'll leave that to the next talk as well to go into some of the details in implementing implementation. 26:00.000 --> 26:10.000 In TIDB we are implementing it in the component that does columns in the store as well. 26:10.000 --> 26:15.000 So then it will stream the data through a raft. 26:15.000 --> 26:18.000 So it will kept always up to date. 26:18.000 --> 26:25.000 And in that part of the architecture that we're all implemented vector index. 26:25.000 --> 26:31.000 Those are presumably the data store mainly compressed and you like to start from a storage perspective. 26:31.000 --> 26:32.000 Yeah. 26:32.000 --> 26:38.000 But that's with a limited time I couldn't do too much. 26:38.000 --> 26:48.000 In high level they use the same kind of algorithm for the indexing and it's all approximate. 26:48.000 --> 26:56.000 So that's again something I wanted to stress that it's different from a data perspective. 26:56.000 --> 27:01.000 You have to use a type flash to use vector and vector it is. 27:01.000 --> 27:02.000 Yes. 27:02.000 --> 27:26.000 I don't know but to create a feature request and we can look into it because I don't think that's anything that's actually hard to change. 27:26.000 --> 27:27.000 Yeah. 27:27.000 --> 27:28.000 Yeah. 27:28.000 --> 27:37.000 And I think it's a post recess half, half vector, some half. 27:37.000 --> 27:38.000 Yeah. 27:38.000 --> 27:40.000 And this is very, very new. 27:40.000 --> 27:47.000 It's not GA in any of these database what I know. 27:47.000 --> 27:55.000 And like the distance function in postgres and Oracle also uses this less than equal, greater than 27:56.000 --> 27:57.000 variance of that. 27:57.000 --> 28:02.000 And that already is taken in my scale for no safe compare I think. 28:02.000 --> 28:05.000 So that's why it needs to be a full functioning. 28:05.000 --> 28:07.000 There was something else. 28:07.000 --> 28:08.000 Yeah. 28:08.000 --> 28:12.000 But the bottom of the form of the comparison is the use of vector. 28:12.000 --> 28:17.000 I saw some of these outcomes and I didn't expect them to search anything. 28:17.000 --> 28:24.960 So for performance I would check Mark Kallahan that has done a good bench 28:24.960 --> 28:42.960 marking between MariaDB and PGVector for TIDBI only seen internal benchmarks against other specific vector databases and so on, which is comparable. 28:42.960 --> 28:49.960 But it's performance in this case is also how exact it is. 28:49.960 --> 28:57.960 The call back rate so how exact was it as well as raw time performance. 28:57.960 --> 28:58.960 So yeah. 28:58.960 --> 29:06.960 It's still a bit of try with your own for a while. 29:06.960 --> 29:07.960 Yeah. 29:07.960 --> 29:09.960 This is more I level. 29:09.960 --> 29:15.960 So you show a earlier that you create a bindings from data as a vector. 29:15.960 --> 29:19.960 And then you create a bindings when you create you from the questions. 29:19.960 --> 29:20.960 Yeah. 29:20.960 --> 29:23.960 Was it asked to use the same model? 29:23.960 --> 29:26.960 Well, you don't use them that when you're creating the prompt. 29:26.960 --> 29:28.960 Then you already have the document. 29:28.960 --> 29:32.960 Then you already use the semantic search for getting all the context and everything. 29:32.960 --> 29:38.960 So when you are actually sending the question to the LLM, that's not anything with vectors and so on. 29:38.960 --> 29:41.960 It's all about the query as well as more context. 29:41.960 --> 29:45.960 But the query you created as a vector compare. 29:45.960 --> 29:46.960 Yes. 29:46.960 --> 29:47.960 Yeah. 29:47.960 --> 29:48.960 So this should use the same. 29:48.960 --> 29:49.960 Yes. 29:49.960 --> 29:53.960 Definitely otherwise you can then it's not even apples and oranges. 29:53.960 --> 29:54.960 There's a new one. 29:54.960 --> 29:57.960 You always have to do all your documents again. 29:57.960 --> 29:59.960 No, no, no, no. 29:59.960 --> 30:01.960 You use the same model, right? 30:01.960 --> 30:02.960 So you're. 30:02.960 --> 30:03.960 Yeah. 30:03.960 --> 30:05.960 Yes. 30:05.960 --> 30:06.960 Yes. 30:06.960 --> 30:09.960 So you can all the vectors to done with one model. 30:09.960 --> 30:14.960 It's completely useless if you use another model. 30:14.960 --> 30:15.960 No. 30:15.960 --> 30:17.960 Maybe I shouldn't ask too much. 30:17.960 --> 30:18.960 We can. 30:18.960 --> 30:20.960 Or answer questions together after the next one. 30:20.960 --> 30:21.960 Yes. 30:21.960 --> 30:23.960 Thank you. 30:23.960 --> 30:25.960 The sweet thing. 30:25.960 --> 30:29.960 Can you do something about the fact that these vectors are straight? 30:29.960 --> 30:30.960 This can be done. 30:30.960 --> 30:31.960 There are. 30:31.960 --> 30:32.960 There are. 30:32.960 --> 30:33.960 There are. 30:33.960 --> 30:35.960 When you you're. 30:35.960 --> 30:36.960 Yeah. 30:36.960 --> 30:37.960 Yeah. 30:37.960 --> 30:39.960 But that's just how you translate. 30:39.960 --> 30:44.960 That's what the cost function would be for, right? 30:44.960 --> 30:47.960 It's not story. 30:47.960 --> 30:54.960 It's all of them are storing 32 bit floats packed. 30:54.960 --> 30:57.960 The box should be set. 30:57.960 --> 31:00.960 The mathematical way. 31:00.960 --> 31:02.960 It's not the screen right? 31:02.960 --> 31:06.400 How would you do that? 31:06.400 --> 31:13.160 You can do that as binary or hex, which is just a bit for the processing of what you 31:13.160 --> 31:14.160 typed. 31:14.160 --> 31:21.400 How would you express that as a string or as binary format? 31:21.400 --> 31:25.320 Well, I don't have to single force. 31:25.320 --> 31:29.400 I have often write it down to 1, 2, 3, and... 31:29.400 --> 31:32.400 OK, so it's the quoting after you are... 31:32.400 --> 31:39.400 You can specify the user, because it's a mobile bit, an implementation. 31:39.400 --> 31:40.400 Yeah. 31:40.400 --> 31:42.400 To make it faster. 31:42.400 --> 31:44.400 But it's not natural. 31:44.400 --> 31:46.400 So if you would create a scratch. 31:46.400 --> 31:52.400 But, I mean, would you actually type in a thousand of numbers? 31:52.400 --> 31:56.400 Or would you have an application that just sends it? 31:56.400 --> 31:59.400 You can read it from you. 31:59.400 --> 32:01.400 They can write a file. 32:01.400 --> 32:02.400 Yeah. 32:02.400 --> 32:03.400 Yeah. 32:03.400 --> 32:11.400 But then you would use an application that sends it a text, and then you don't have any quoting. 32:11.400 --> 32:15.400 Or you would already parse it and send it as floats. 32:15.400 --> 32:23.400 And we are also typed to what the model responds. 32:23.400 --> 32:25.400 So this is the answer. 32:25.400 --> 32:27.400 We'll get this a string, of course. 32:27.400 --> 32:30.400 Then this is the string I received from the bottom. 32:30.400 --> 32:32.400 We'll get the binding. 32:32.400 --> 32:35.400 We'll get that, and then you send it to your database. 32:35.400 --> 32:37.400 And you get it in a string. 32:37.400 --> 32:43.400 And something I just want to say that, if you want to play with this, if you have your own documentation, 32:43.400 --> 32:50.400 we actually released an open source out of flow, which is super easy to create your own AI assistant or 32:50.400 --> 32:53.400 conversant search page. 32:53.400 --> 32:59.400 So we have this, we call it the TIDBAI as a demo more or less. 32:59.400 --> 33:06.400 Where you can use for asking anything about TIDBAI, that will be generated from our documentation. 33:06.400 --> 33:07.400 Yeah. 33:07.400 --> 33:08.400 And here you can choose. 33:08.400 --> 33:14.400 You can, it's a lot of JavaScript and so on, but it's a great website for you. 33:14.400 --> 33:17.400 You tell it which model you would use. 33:17.400 --> 33:20.400 You point your own documentation and so on. 33:20.400 --> 33:22.400 So it's a whole framework for actually doing it. 33:22.400 --> 33:25.400 It makes it super easy to play around with it. 33:25.400 --> 33:31.400 And it might actually be really useful if you have internal documentation or whatever you want 33:31.400 --> 33:34.400 to add an AI functionality to it. 33:34.400 --> 33:36.400 Thank you very much.