Yandex search from an engineering point of view. Lecture in Yandex

    Today we publish another of the reports made at the summer meeting about the Yandex search device. The speech of the head of the ranking department Peter Popov that day turned out to be the most accessible for a wide audience: a minimum of formulas, a maximum of general concepts about search. But it was interesting to everyone, because Peter went over to the details several times and as a result told a lot of things about which Yandex had never publicly announced before.

    By the way, simultaneously with the publication of this decryption, the second meeting begins in a series devoted to Yandex technologies. Today's event is no longer about search, but about infrastructure. Here is the broadcast link .


    Well, under the cut - a lecture by Peter Popov and part of the slides.



    My name is Peter Popov, I work at Yandex. I've been here for about seven years. Before that, he programmed computer games, was engaged in 3D-graphics, knew about video cards, wrote in SSE assembler, in general, he was engaged in such things.

    I must say that when I got a job at Yandex, I knew little about the subject area - about what people do here. I only knew that good people work here. Therefore, I had some doubts.



    Now I will tell you quite fully, but not very deeply, about how our search looks. What is Yandex? This is a search engine. We must receive a user request and form the top ten results. Why exactly the top ten? Users rarely go to farther pages. We can assume that ten documents is all that we show.

    I don’t know if there are people in the hall who are engaged in Yandex advertising, because they believe that the main Yandex product is completely different. As usual, there are two points of view and both are correct.

    We believe that the main thing is the user's happiness. And, surprisingly, this happiness depends on the composition of the tens and how the ten is ranked. If we worsen the issuance, users use Yandex less, go to other search engines, and feel bad.



    What design did we build to solve this simple task - to show ten documents? The design is quite powerful, from the bottom, apparently, the developers look at it.

    Our work model. We need to do just a few things. We need to go around the Internet, index the resulting documents. The document we call the downloaded web page. Index, add to the search index, run a search program over this index, and respond to the user. In general, everything, profit.

    Let's go through the steps of this conveyor. What is the Internet and how much is it? The Internet, consider it infinite. Take any site that sells something, some online store, change the sorting options there - another page will appear. That is, you can set the CGI parameters of the page, and the content will be completely different.

    How many fundamentally important pages do we know up to discarding insignificant CGI parameters? Now - about a few trillions. We download pages at a speed of the order of several billion pages per day. And it would seem that we could complete our work in a finite time, there, in two years.

    How do we even find new pages on the Internet? We went around some page, pulled out links from there. They are our potential victims for download. Perhaps in two years we will bypass these trillions of URLs, but new ones will appear, and links to new pages will appear in the process of parsing documents. It is already evident here that our main task is to deal with the infinity of the Internet, having on hand the ultimate engineering resources in the form of data centers.

    We downloaded all the crazy trillions of documents, indexed. Next you need to put them in the search index. We do not put everything in the index, but only the best of what we downloaded.



    There is comrade Ashmanov, a well-known specialist in narrow circles in Internet search engines. He builds different quality graphs of search engines. This is a graph of the completeness of the search base. How is it built? A request is made from a rare word, it looks what documents are in all search engines, this is 100%. Every search engine knows about some share. We are in red above and below in black is our main competitor.

    Here you may wonder: how did we achieve this? There are several possible answers. Option one: we parse the page with these tests, tear out all the URLs from there, all the requests that Comrade Ashmanov sets and index the pages. No, we didn’t do that. The second option: for us, Russia is the main market, and for competitors, it is something marginal, somewhere on the periphery of vision. This answer has the right to life, but I also do not like it.

    The answer that I like is that we did a lot of engineering work, did a project called the "big base", bought a lot of iron for it, and now we are seeing this result. A competitor can also be beaten, it is not iron.



    We downloaded the documents. How do we build a search base? Here is a diagram of our content system. There is Internet, a cloud of documents. There are cars that bypass him - spiders, spiders. We downloaded the document. To begin with - put it in a saved copy. This is, in fact, a separate inter-center hash table where you can read and write in case we later want to index this document or show the user as a stored copy on delivery.

    Next, we indexed the document, defined the language, and pulled out the words, reduced according to the morphology of the language to the main forms. We also pulled out links leading to other pages.

    There is another data source that we widely use when building the index and generally in ranking - Yandex logs. The user asked the request, received a dozen results and somehow behaves there. Documents seemed to him, he clicks or does not click.

    It is reasonable to assume that if the document appeared in the search results, or, moreover, if the user clicked on it, had some kind of interaction, then such a document should be left in the search database. In addition, it is logical to assume that links from such a good document lead to documents that are also good and that it would be nice to prioritize downloading. Here is a tour planning. The arrow from the bypass planning should lead to the bypass.

    Next is the stage of building a search index. These rounded rectangles lie in MapReduce, our own implementation of MapReduce called YT, Yandex Table . Here I varnish a little - in fact, building a base and sharding operate on indexes as with files. We fix it a little bit. These rounded rectangles will lie in MapReduce. The total amount of data here is about 50 PB. Here they turn into search indexes, into files.

    There are problems in this circuit. The main one is due to the fact that MapReduce is a purely battle operation. To determine the priority documents for a workaround, for example, we take the entire link graph, wezhim it with all the user behavior and form a queue for the jump. This process is quite latent, taking some time. Exactly the same with the construction of the index. There are processing stages - they are batche for the entire base. And the layout is also arranged, we either lay out the delta, or that's it.

    An important task with these volumes is to speed up the index delivery procedure. I must say that this task is difficult for us. We are talking about the fight against the batch character of building the base. We have a special fast circuit that downloads all kinds of news in real time, informs the user. This is our line of work, what we do.



    And here is the second side of the coin. The first is a content system, the second is a search. You can understand why I painted the pyramid - because Yandex search really looks like a pyramid, such a hierarchical structure. Above are balancers, fronts that generate extradition. A little lower - aggregating metasearch, which aggregate the issuance from different verticals. I must say that at the extradition you probably saw web documents, videos and pictures. We have three different indexes, they are interrogated independently.

    Each of your search queries goes down this hierarchy and goes down to each piece of the search base. We have divided the entire index that we built into thousands of pieces. Conditionally, for two-three-five thousand. A search was lifted over every piece, and this query went down everywhere.



    You can immediately see that Yandex search is a big thing. Why is she big? Because we keep in our memory, as you saw on the previous slides, a fairly representative and powerful piece of the Internet. We store more than once: in each data center from two to four copies of the index. Our query goes down to each search, in fact, it goes through each index. Now the used data structures are such that we are forced to store all this directly in RAM.



    What do we have to do? Instead of expensive RAM, use a cheap SSD, speed up the search, say, twice, and get a profit - tens or hundreds of millions of dollars of capital costs. But there’s no need to say: crisis, Yandex saves and all that. In fact, everything that we save, we will put into useful work. We will double the index. We will search for it better. And that’s why this kind of complex engineer is being carried out. This is a real project, though quite heavy and sluggish, but we really do, we want to improve our search.

    The search cluster is not only large enough - it is also very complex. Millions of instances of different programs are really spinning there. At first I wrote - hundreds of thousands, but the comrades from the operation corrected me - still millions. On each machine in very many copies, 10-20 pieces are exactly spinning.

    We have thousands of different types of services spread across the cluster. It should be clarified: a cluster is such machines, hosts, programs are running on them, they all communicate over TCP / IP. Programs have different consumption of CPU, memory, hard drive, network - in short, all these resources. Programs live on hostels in a hostel. More precisely, if we put one program on the host, then there will be no cluster utilization. Therefore, we are forced to lodge programs with each other.

    Next slide about what to do with it. And here is a small remark that we download all the program data, all releases using torrents, and the number of distributions on our torrent tracker exceeds that on Pirate Bay. We are really big.

    What needs to be done with all this cluster design? There is a need to improve virtualization mechanisms. We are really investing in the development of the Linux kernel, we have our own container management system a la Docker, Oleg will tell you more about it.

    We need to plan ahead on which hosts which programs to host each other, which is also a difficult task. We are constantly going to the cluster. Now there are probably ten releases rolling.

    We need to correctly deploy programs with each other, we need to improve virtualization, we still need to combine two large clusters - a robot and a search one. We somehow independently ordered iron and thought that there were separate machines with a huge number of drives and separately - thin blades for searching. Now we realized that it is better to order unified hardware and run MapReduce and search programs in isolation: one eats mostly drives and a network, the second mainly CPUs, but they have a balance on the CPU, you need to twist it here and there. These are large engineering projects that we are also conducting.

    What do we get from this? Benefits of tens of millions of dollars in capital cost savings. You already know how we will spend this money - we will spend it on improving our search.

    Here I talked about the design as a whole. Some separate building blocks. People blasted these blocks with a chisel, and they did something.



    Ranking function Matrix. A fairly simple function. You can read - there are binary signs of the document in the vector, and in this cycle, the relevance is calculated. I am sure that among you there are specialists who are able to program on SSE, and they would have quickened this ten times faster. So it happened at some point. A thousand lines of code saved us 10-15% of the total CPU consumption on our cluster, which again amounts to tens of millions of dollars of capital expenses that we know how to spend. This is a thousand lines of code, which are very expensive.

    We more or less cleaned it from the repository, optimized it, but there is still something to be done.

    We have a platform for machine learning. Indexes from the previous slide need to be selected greedily, sorting through all the possibilities. This takes a long time on the CPU. On the GPU - quickly, but the training pools do not go into memory. What do we have to do? Or buy custom solutions, where many of these glands are stuck, or connect machines quickly, use some kind of interconnect, infiniband, learn to live with it. It is typically buggy, does not work. This is a very funny engineering challenge that we also face. It would seem that it is not at all connected with our main activity, but nonetheless.



    What we are still investing in is data compression algorithms. The main task of compression looks something like this: there is a sequence of integers, you need to compress it somehow, but not just compress it - you also need to have random access to the i-th element. A typical algorithm is to compress this in small blocks, to have markup for a common data stream. Such a task is completely different than contextual compression like zip or LZ-family. There are completely different algorithms. Can be compressed with Huffman, Varlnt, blocks like PFORX. We have our own proprietary algorithm, we are improving it, and this again is 10-15% of RAM saving for a simple algorithm.

    We have all sorts of funny little things, such as improvements to the CPU, Linux schedulers. What's the problem with Intel's hyper-stones? That there are two threads on the physical core. When two threads occupy two threads there, they work slowly, latency increases. You need to correctly scatter tasks on physical processors.

    If you throw it right, and not like the stock planner does, you can get 10-15% latency of our request, conditionally. This is what users see. Multiply the saved milliseconds by the number of searches - that’s the time saved for users.

    We have some very strange things like our own implementation of malloc, which actually does not work. It works in arenas, and each location simply moves the pointer inside this arena. Well, the ref counter of the arena raises by one. The arena is alive, while the last location is alive. For any mixed load, when we have a short-lived and long-lived location, this does not work, it looks like a memory leak. But our server programs are not so arranged. A request arrives, we allocate internal structures there, somehow work, then give the answer to the user, everything is demolished. This allocator works perfectly for our stateless server programs. Due to the fact that all locations are local, consistent in the arena, it works very quickly. There are no page faults, cache miss, etc.

    This is an engineer, what else can I do? You can do machine learning. Sasha Safronov will tell you about this with love .

    And now questions and answers.

    I will take the question I liked very much that came to the newsletter and which should be included in my presentation. Comrade Anatoly Drapkov asks: there is a famous slide about how quickly the formula grew before the introduction of the MatrixNet. In fact, both before and after. Are there any growth problems now?

    The growth problems we face are in full growth. Another order of increasing the number of iterations in the ranking formula. Now we are doing about 200 thousand iterations there in the MatrixNet function to respond to the user. Was obtained by the next engineering step. We used to rank on the base. This means that each basic one launches a Matrixnet and produces a hundred results. We said: let us combine the best hundred results on average and arrange once again with a very difficult formula. Yes, we did it, on average, you can calculate the MatrixNet function in several threads, because you need a thousand times less resources. This is a project that allowed us to achieve the next order of increasing the volume of the ranking function. What else will happen - I do not know.

    Andrey Styskin, head of Yandex Search Products Department:
    - How many bytes did the first Yandex ranking formula occupy?

    Peter:
    - A dozen, probably.

    Andrew:
    - Well, yes, probably a hundred characters somewhere. And how much does the Yandex ranking formula take now?

    Peter:
    - Somewhere 100 MB.

    Andrew:
    - The formula of relevance. This is for our broadcast watchmen, SEO experts. Try reengineering our 100MB ranking.

    Alesya Bolgova, Intel:
    - On the last slide about malloc, could you explain how you allocate memory? Very interesting.

    Peter:
    - An ordinary page is taken, 4 KB, at the beginning it has a rev counter, and then we have each allocation ... if small allocations are less than a page, we simply move in this page. In each thread, of course, this page has its own. When the page was closed - that's all, they forgot about it. The only thing she has is rev counter at the beginning.

    Alesia:
    - So you highlight the page?

    Peter:
    - Inside the page with allocations, we are growing like this. The only thing is that the page lives as long as the last allocation in it lives. For a normal workload, it looks like a leak, for ours it looks like a normal job.

    - How do you determine the quality of a page, is it worth putting it in an index or not? Also machine learning?

    Peter:
    - Yes, of course. The page has many factors, from its size to the impressions on the search, to ...

    Andrew:
    - Before the robot rank. It is located on some host, in some host subdirectory, there are some incoming links to it. Those who refer to it have some quality. We take all this and try to predict with what probability, if this page is downloaded, it will contain information that will be sent to a request by some request. This is predicted, the top is selected taking into account the size of the documents - because depending on the size of the document, the probability that it will get at least for some request increases. The task of optimal filling of the backpack. It is selected taking into account the size of the document and the top one is placed in the index.

    - ...

    Andrey:
    - Let's introduce you first.

    - Maybe not worth it?

    Andrew:
    - Vladimir Gulin, head of search engine ranking Mail.Ru.

    Vladimir:
    - My first question is about the number of searches in general. You said that you dramatically increased the size of the base there. I would like to understand at all how much you started, what was the volume of the Russian index, foreign index, how many documents each shard had, well, after the increase ...

    Peter:
    - These are such numbers, too technical. Maybe on the sidelines I would say. I can say how many times we have approximately increased - by one and a half orders of magnitude somewhere. 30 times, conditionally. Over the past three years.

    Vladimir:
    - Then I will specify the absolute numbers on the sidelines.

    Peter:
    - Yes, for a fee, as they say.

    Vladimir:
    - Okay. As for freshness - what is the volume of the fast index around Yandex now? And in general, how fast are you updating, mixing it all up?

    Peter:
    - The index is really real-time, there are about two minutes of latency there to add a document to the index. From the moment we indexed it, and the discovery, too, is a quick leap.

    Vladimir:
    - But just to find the document. First you need to find out that the document exists.

    Peter:
    - I understand that this question is not clear when the first link to this document appeared on the Internet. When we found out the first link, then it’s a matter of minutes in the quick layer.

    Andrew:
    - We are talking about millions of documents that are in this fast index every day. Usually, there is a lot of external information about them: a mention on Twitter, sitemaps, a mention of news on the Lenta.ru website. And since we pump the face of Lenta.ru almost every second, we quickly find these documents and, within a few minutes, deliver them to the search in the worst case. They can be searched. Compared to the large index, we are talking about a dramatically small number of documents, these are millions.

    Peter:
    - Yes, 3-4 orders of magnitude less.

    Andrew:
    - Yes, these are millions of documents that can update real time.

    Vladimir:
    - Millions of documents per day?

    Peter:
    - A little bit more, but something like that, yes.

    Vladimir:
    - Now the question is about mixing fresh results and the results of the main search.

    Peter:
    - We have two ways of mixing. One - the document is ranked in the same formula as a regular ordinary document. And the second is a special news mix when we determine the intent of the request, understand that it is really fresh and that something needs to be shown. Two ways.

    Vladimir:
    - How do you deal with a situation where you get fresh results for popular queries, where are the clicks? How do you determine that a fresh result should be shown above that result that is already posted? They asked you: "Google." You kind of know what results on such a query are good. Nevertheless, there is something else in the news, some articles ...

    Peter:
    - These are all kinds of query factors, all kinds of trends and all that.

    Andrey:
    - For everyone I’ll explain what the complexity of the task is and what the question is. About the document, which has existed for a long time on the Internet, we know a lot of things. We know a lot of links to it, we know how much time people spent on it, and we don’t know all about fresh documents. Therefore, the complexity of the task of ranking fresh documents and news is to guess whether people will read it, to be able to predict the number of links that he will gain in some time to show it normally. And to mix documents at the request of “Google”, when Google did something good, there exists a certain optimization metric, which we call a surplus. We can optimize it.

    Peter:
    - We know the flow of requests, the content of the freshly downloaded pages. We can analyze and understand these two things, that a really fresh request requires mixing.

    Andrey:
    - And then, on the basis of manual evaluation and user behavior on this very second on this day, we understand that today, this news on demand is important and it has such factors: the document just appeared, there are so many retweets on it. And so the next news, which will be with the same distribution of characteristics, also needs to be shown when it picks up the corresponding values.

    Peter:
    —And the factors there may be such: the number found in the usual layer versus the number found by this request in the fresh. Such, the most naive, although we carefully cut it.

    Andrew:
    - For those who are afraid of the word “factors”, there will be a special third report, where we will tell you basic principles - how machine learning is generally arranged, ranking, what factors are, how to use this to make a search engine that produces good, good results.

    Vladimir:
    - Thank you, I will ask the rest later.

    Nikita Pustovoitov:
    - It turns out that you have a large number of urls that you basically know about, and you can download several orders of magnitude less. Since new ones will appear during the download, you will never visit again. For the choice of machine learning, some kind of heuristics?

    Peter:
    —Only machine learning. The idea there is simple: we have a signal for some document, any, the number of impressions, and we distribute it according to the reference graph. We aggregate all this on the “target of the link” page, then by machine learning we also train the chance to appear based on this data.

    Nikita:
    - The second question is engineering. You said that you have a lot of CPU-intensive tasks. Have you considered using Intel's Xeon Phi processor? It seems to work much faster with RAM than the GPU.

    Peter:
    - We considered it for the problems of training precisely our Matrixnet, our formula, and there he enchantingly badly showed himself. And in general, our profile is very flat, we have a top-end function somewhere around 1.5%. We have optimized everything that we can with our hands, and so we have footcloths C ++ - code that does not fit there.

    - As far as I know, Yandex was the first search engine to start working with Russian morphology. Tell me, at the moment this is still some advantage or all the search engines work equally well with Russian morphology?

    Peter:
    - Now in the field of morphology, science does not stand still. Sasha Safronov will tellabout what we are achieving now, there really are new approaches and new ways to solve problems. For example, defining queries similar to this by user behavior. Not the expansion of individual words, but the expansion of queries by queries.

    Andrei:
    - That is, it is not quite morphology. Indeed, probably all search engines have mastered morphology more or less, but this is a basic thing. But linguistics, finding what and what query words can be expanded, what other things are worth looking in the document to find candidates who will be more relevant - this will be the third report. There is our know-how, we will tell.

    Peter:
    - At least we’ll hint.

    Andrey (viewer):
    - Thank you for a brief excursion into such a sophisticated technology as Yandex search. Does Yandex use deep learning and reinforcement learning algorithms in building a quick index or cache? In general, if you use somewhere, then how?

    Peter:
    - We use Deep learning in order to train ranking factors. Regardless of fast or slow index. It is used for pictures, the web and all that.

    Andrei Styskin:
    - In the summer we launched the ranking version, which gave a 0.5% increase in quality, where we correctly welded deep learning in words. Our former colleagues came from abroad and told us that this does not work there, and we learned.

    Peter:
    - Or maybe it's because we do it for the top 100 documents. This is a very expensive task. Our way to build a search pipeline allows hundreds of documents to do this.

    Andrey Styskin:
    “It is impossible to calculate deep learning for all candidates who are hundreds of millions inquiries, but for the top of documents you can crank it out, and this search scheme works exactly like this for us - it allows us to implement such very complex high-tech algorithms.

    Igor:
    - About the future of the search engine as a whole. The Internet is now growing very fast, the volume is probably growing exponentially. Are you sure that in 10 years you will keep pace with the growth of the Internet, and are you sure that you will cover it in the same volume? Repeat again, to what extent is the Internet now covered by your assessment, and what will happen in 10 years?

    Peter:
    - Unfortunately, you can only determine the degree of coverage as a percentage of someone. Because it is really endless.

    Andrew:
    - This is a beautiful philosophical question. While we in our team keep up with Moore’s law, each year we increase our base size by a factor of several. But it’s really difficult, really interesting, and, of course, we don’t even have enough hands to do it, but we want and know how to increase this over the next few years with some series of improvements.

    Peter:
    - 10 years is too far, but yes, we will master it in the coming years.

    Andrey (viewer):
    - How much does an Internet replica weigh, how is it distributed between DCs, and how are replicas synchronized?

    Peter:
    - The total volume of robotic data is about 50 PB, the replica is smaller, the index is smaller. You can multiply by a factor that seems reasonable to you. You’re an engineer.

    Andrew:
    - And how is it carried?

    Peter:
    - It spreads trite - through torrent, torrent share. Then download this file.

    Andrew:
    - That is, at some point in time they are not consistent?

    Peter:
    - No, then there are consistent switching. It happens that we switch to DC when it is suddenly not consistent at night.

    Andrew:
    - That is, it is possible through F5 - if we click, we have one document ...

    Peter:
    - We are struggling with this problem, we know about it, its solution is in our plans.

    Ivan:
    - How do you fight with various bot systems and what can you go into a ban for?

    Peter:
    - We have special people who know the answer to this question, but they will not say.

    Andrey Styskin:
    - At today's event, we wanted to talk about technical details.

    Peter:
    - About the robot trap, we can answer. We are really regularly beaten up, therefore, right on the balancer, on the first layer, when the request arrives, there is a detection that the request from some network came unsuitable. This is updated quickly, we quickly redirect, it does not bring down our cluster.

    Andrew:
    - And this is also arranged by machine learning. A captcha is shown, and depending on how you solve it, we get positive and negative examples. On some factors - such as IP subnet, some behavior, time between actions - we train and ban or don’t ban such requests. DDoS will fail.

    Andrey Aksyonov, Sphinx Search:
    - I have technical questions. Passing question - why memory? Is it really impossible to even search for SSDs so that the index does not fit in a little, occasionally it rests on SSDs?

    Peter
    - It turns out that the footprint of one request is about 50-100 MB, it’s directly tough. At this speed, you will not be able to serve a thousand requests per second, as we want. We are working to reduce this footprint. The problem is that the data about the document is scattered throughout the disk. We want to collect them in one place, and then our common dream will come true.

    Andrey Aksyonov:
    - Rests against bandwidth or latency?

    Peter:
    - Both. We consistently page fold, and the volumes are large.

    Andrei Aksyonov:
    - That is unbelievable, but true: even if a little ...

    Peter:
    - Yes, even if you eat a little - that's all.

    Andrei Aksyonov:
    - An exponential drop many times?

    Peter:
    - Yes, yes.

    Andrey Aksyonov:
    - Now the most important question for the industrial economy: how many row classes and vector classes in the database?

    Peter:
    - But less and less.

    Andrey Aksyonov:
    - Well, more specifically.

    Peter:
    - The right people have come to us, they are planting the correct orders. Now this number is decreasing.

    Andrey Aksyonov:
    - How many vectors and lines?

    Peter:
    - Now vectors, probably even one or two maximum.

    Andrei Aksyonov:
    - One does not happen, two at least ...

    Peter:
    - Well, you see.

    Andrey Aksyonov:
    - And the lines?

    Peter:
    - Well, there must be some corporate spirit of Yandex.

    Andrey Aksyonov:
    - Tell me, don’t tom, well.

    Peter:
    - Lines two minimum. Well, maybe three.

    Andrey Aksyonov:
    - Not five?

    Peter:
    - Not five.

    Andrey Aksyonov:
    - There is progress, thanks.

    Fedor:
    - About your scheme with meta-searches. You have a very high cascade. What timings at each level can you voice?

    Peter Popov:
    - Right now we are inserting another layer, not enough. Response times ... An average meta-search does three rounds of going back and forth, it has about 250 ms, the 95th quantile. Further, the construction of the output is not very fast, but the whole structure fulfills somewhere in 700 ms.

    Andrey Styskin:
    - Yes, there is higher JavaScript, so it is 250 ms, and there is 700.

    Peter:
    - What is below, it makes a bunch of rounds. Our specialists are also busy right now solving this problem.

    Fedor:
    - You have drawn three groups of verticals. But you still have a poster, news and so on. Where do you knead them in the end?

    Peter:
    - In the construction of the issuance, we have such a blender that combines all these verticals, according to user behavior, decides who to show. This is just the construction of the issue.

    Andrey:
    - There are hundreds of verticals; this is a layer called the upper metasearch. It merges the results of average meta-searches from the vertical of the web, Images, Videos and several others, as well as from small basic sources such as Posters, Schedules, TV and Electric trains.

    Peter:
    - This is to the question of why we have thousands of different types of programs. There are a lot of all sorts of sources;

    Fedor:
    - Since you have so many verticals, are there any third-party ones that you don’t think?

    Peter:
    - Not really. Our advertising is also vertical, separate from the search, but there is not much third-party advertising.

    Artyom:
    - Your main competitor has always had real time issuance; And Yandex had up issuance. One got the impression that on a dark night every seven days a person presses the lever and rolls the indexes.

    Peter:
    - Unfortunately, this is happening.

    Artyom:
    - I understand correctly that the quick index was made in order to update the issuance of real time?

    Peter:
    - Yes, but the decision is common. Many really do this, including our main competitor.

    Artyom:
    - Do you strive to throw up delta indices too, just abandon the fast index?

    Peter:
    - Naturally, we strive. Still to know how.

    Artyom:
    - When can this be expected?

    Peter:
    - Good question. On the same graphs Ashmanov shows how we update the index. Now this is less visible, and we are doing it so that it passes very quickly and quietly. This is one of our tasks.

    Artyom:
    - Do you process a user request each time? A request arrives, you send it to the backend, is the formula calculated and the result?

    Peter:
    - There are caches, but they work in 50% of cases. 40-50% of user requests are unique and will never be asked again. A lot of truly unique user requests in general for the whole life of Yandex. We cache 50-60%. There is also a system for caching.

    Also popular now: