company_banner

Как решать проблемы пользователей не за сутки, а за минуты: ускоряем поиск по логам

    Мы в Почте Mail.Ru постоянно сталкиваемся с необходимостью работать с историей пользователей. Учитывая, что ежемесячная аудитория проекта составляет более 40 миллионов человек, история всех их действий – это порядка петабайта данных. Потребность в поиске по логам у нас возникает сотни раз в день, а на получение нужной информации в среднем уходило несколько часов. При этом, по нашим предположениям, извлечение информации из логов можно было ускорить до нескольких секунд.

    Чтобы оценить целесообразность разработки системы для оптимизации поиска по логам, мы воспользовались вот этой таблицей с XKCD:



    (на самом деле нет, но нам она все равно нравится).

    Итак, мы всерьез взялись за оптимизацию. Итогом нашей работы стала разработка системы, благодаря которой мы можем поднять историю действий примерно в 100 000 (сто тысяч, это не опечатка) раз быстрее. Мы разработали big-data сервис, который позволяет хранить петабайты информации в структурированном виде: каждому ключу у нас соответствует лог каких-то событий. Хранилище устроено так, что оно способно работать и на самых дешевых SATA-дисках, и на больших многодисковых хранилищах с минимальным количеством процессорного времени, при этом оно полностью fault-толерантно — если вдруг какая-то машина выйдет из строя, это ни на что не влияет. Если в системе заканчивается место, в нее просто добавляется сервер или несколько: система автоматически увидит их и начнет записывать данные. Чтение данных происходит почти моментально.

    В чем подвох?



    Зачем это нужно? Допустим, у пользователя что-то не работает. Чтобы воспроизвести ошибку, нам нужно знать всю предысторию: куда человек заходил, на какие кнопки и ссылки кликал. Также логи бывают необходимы для принятия решений в таких случаях, как взлом аккаунта пользователя, когда важно разделить действия пользователя и злоумышленника.

    Соответственно, на скорость поиска по логам «завязана» скорость ответа технической поддержки сервиса.

    За рабочий день большой системы может накопиться несколько терабайт логов, особенно учитывая, что в нашей компании много «сложносочиненных» сервисов. Допустим, пользователь зашёл в почту, почта обратилась в базу данных, база — в систему хранения, та тоже записала логи… Чтобы понять, что делал пользователь, все эти данные нужно собрать в кучу. Для этого используется старая добрая команда grep, от которой пошло слово «грепать». Для решения проблемы одного пользователя мы грепаем, например, терабайт. Этот процесс может занимать несколько часов. Мы озаботились этой проблемой и стали думать, как обрабатывать эти данные гораздо быстрее.

    Проблема в том, что полноценных отдельных систем для хранения и обработки логов, соответствующих нашим задачам, пока не существует. Например, Hadoop (как и любая другая реализация MapReduce) может параллельно грепать логи и собирать воедино результаты. Но, поскольку в Почте и Облаке Mail.Ru объём логов, которые нужно хранить, оценивается в петабайт, даже параллельная обработка такого объёма потребует большого количества времени. Кроме того, при грепе за сутки надо пройтись по нескольким терабайтам, а при грепе за неделю этот объем может вырасти и до десятка терабайт. Плюс, если нужно грепать по большому количеству разных логов, то для решения всего лишь одной проблемы может потребоваться греп нескольких десятков терабайт логов.

    Жёсткие диски могут линейно записывать информацию со скоростью около 100 Мбит/сек. Однако быстрая запись подразумевает неструктурированность, неоптимальность размещения информации. А для быстрого чтения файлов необходимо, чтобы они были определённым образом структурированы. Нам же требовалось обеспечить высокую скорость обоих процессов. В логах постоянно сохраняется большой объем информации, при этом нам нужно быстро собирать статистику по конкретному пользователю, чтобы оперативно решать возникающие у него проблемы, обеспечивая качественную техническую поддержку.

    Можно было бы пойти по самому простому пути, организовав хранение логов в базе данных. Но это очень и очень дорогое решение, поскольку оно требует использования SSD-дисков, шардирования БД, создания реплик. Мы же хотели найти решение, которое позволило бы нам работать с максимально дешёвым хранилищем на медленных дисках огромного объёма.

    С учетом всех этих факторов было решено с нуля написать систему, позволяющую ускорить процесс грепания. Кстати, насколько мы знаем, аналогов у нее нет не только в России, но и в мире.

    Как мы это сделали?



    Система, которую мы для этого создали, устроена следующим образом. С точки зрения программиста она выполняет, по сути, две операции: создание записи по конкретному пользователю (ID и время) и получение всей истории по конкретному пользователю.

    Запись осуществляется в нашу БД Tarantool. В ней вся информация всегда сохраняется в один файл, а чтение осуществляется из памяти. База шардирована на несколько инстансов. Сами логи хранятся на многодисковых серверах. Поскольку Tarantool всё хранит и в памяти, и на диске, понятно, что бесконечно это продолжаться не может. Поэтому периодически запускается процесс, который группирует по пользователям данные из Tarantool и записывает их в файлы на серверах, а в БД ставит ссылку на эти данные.

    Таким образом, в Tarantool хранится лишь недавняя история по пользователям (соответственно, ее можно быстро извлечь). А «старые» данные складируются на дисках в одном большом файле, хорошо структурированном и пригодном для быстрого чтения. Благодаря этому всю историю по любому пользователю можно получить за считанные секунды. Для сравнения: до этого грепание недельного периода по одному пользователю занимало около трёх дней.

    На каждом диске хранится несколько файлов, в которые подряд записывается вся информация по разным пользователям. Чтобы Tarantool не переполнялся, делается следующее: процесс, который последовательно читает все эти файлы, берёт информацию о пользователе из файла целиком, добавляет к нему то, что есть в Tarantool, и записывает всё это опять в конец файла. Вся эта система ещё и шардирована и реплицирована, то есть серверов может быть сколько угодно, потому что каждый раз, когда мы перезаписываем заново историю пользователя, мы записываем её всегда на два диска, которые выбираются произвольно. После успешной парной записи ссылка сохраняется в Tarantool. Таким образом, если даже один из серверов упадет, то информация не пропадает. При добавлении нового сервера он прописывается в конфигурацию системы, после чего на него автоматически начинаются сохраняться новые данные.

    Сейчас эта система используется в Почте и Облаке Mail.Ru. В ближайшее время мы планируем внедрить её в «Mail.Ru для бизнеса», а потом постепенно и на остальных проектах.

    Как это работает?

    Мы осуществляем поиск по логам в двух типах случаев. Во-первых, для решения технических проблем. Например, пользователь жалуется на то, что у него что-то не работает, и нам нужно быстро посмотреть всю историю его действий: что он делал, куда заходил и так далее. Во-вторых, если у нас возникает подозрение, что произошел взлом ящика. Как я уже говорил выше, в этом случае история нужна для того, чтобы разделить действия пользователя на его собственные и совершенные злоумышленником.

    Приведу несколько примеров того, насколько эффективна созданная нами система.

    Довольно частый кейс: пользователь жалуется на пропажу писем из почтового ящика. Мы поднимаем историю и смотрим, когда и из каких программ он их удалял. Допустим, мы видим, что письма были удалены с такого-то IP-адреса через POP3, из чего делаем вывод, что пользователь подключил себе POP3-клиент и выбрал опцию «Скачать все письма и удалить их с сервера» — то есть на самом деле письма были удалены пользователем, а не «пропали сами». Благодаря нашей систематизированной системе хранения логов мы можем установить этот факт и продемонстрировать его пользователю в считанные секунды. Экономия времени админов и саппорта – гигантская.

    Другой пример: мы получаем жалобу от пользователя, который не может открыть письмо. Подняв все логи по этому пользователю, мы можем буквально в течение нескольких секунд посмотреть, когда и какие серверные вызовы делались, какими юзер-агентами, что происходило со стороны клиента. Благодаря этому мы можем легче и, главное, гораздо быстрее установить, в чем же проблема.

    Еще случай — пользователь жалуется на то, что не может войти в почтовый ящик. Мы начинаем искать причину — выясняется, что аккаунт был автоматически заблокирован за рассылку спама. Тут нужно разобраться, кто именно спамил – сам пользователь или кто-то другой от его имени, а для этого придется проанализировать всю историю использования ящика за длительный период (возможно, неделю, месяц или даже больше). Заглянув в историю, мы видим, что, начиная с определённой даты, в его ящик заходили из подозрительного (т.е. «неродного» для пользователя) региона. Очевидно, что его просто взломали. Причём сбор данных и анализ занял не сутки, а несколько секунд: сотрудник техподдержки просто нажал на кнопку и получил исчерпывающую информацию. Пользователь поменял пароль от ящика и снова получил к нему доступ.

    Одним словом, наша система ежедневно экономит нам кучу времени, при этом позволяя сократить время ответа пользователю – по-моему, это win. О других способах ее применения мы расскажем в следующих постах.
    Mail.Ru Group 694,69
    Строим Интернет
    Поделиться публикацией
    Комментарии 64
      +13
      А где код? где ссылка на гитхаб? я так не играю. Поманили, вот у нас есть инструмент, а другим инструмент не дали, обидно.
        +1
        Мы в будущем, возможно, выложим в аутсорс. Система, действительно, получилась очень крутая и очень неприхотливая с точки зрения железа.
          +5
          Простите, опечатался, имел в виду оупенсорс
            0
            Ну как сказать, опенсорс и аутсорс для кого-то одно и тоже… )
              0
              Оговорочка по Фрейду, вы имеете в виду :)
              На самом деле, мы аутсорсом почти не пользуемся, все стараемся делать in the house.
        +4
        А чем не подошла Cassandra? Там линейная запись на диск, но при этом упорядочивание по ключам.
        Можно сделать составной ключ email + день + время, и получите то же самое.
        Используем это подход для хранения наших логов со всех серверов.
          +2
          смею предположить из-за того, что у них есть свой Tarantool.
            0
            Вместо Tarantool можно было бы использовать любой key-value with persistence. Но для нас Tarantool хорошее, проверенное в бою решение, и к тому же на наших нагрузках работающее быстрее чем любой другой open source key-value, которые мы тестировали.
            +2
            Кассандра, как и прочие map reduce системы не позволяют искать мгновенное. Они лишь позволяют убыстрить этот процесс путем параллельных запросов по большому количеству дисков. Т.е. поиск среди 100Тб, распределенных по 100 дискам в map reduce системе будет занимать несколько часов. Это, конечно, быстрее, чем две недели, но все равно долго.
              0
              Кассандра — не map/reduce. Это тупое key-value хранилище, но зато очень быстрое, при правильной схеме.
              В вашем случае я бы сделал partition key = email+day, clustering key = time
              Кассандра ищет по ключу мгновенно. Значит, если нужны логи по конкретному пользователю за пару дней, нужно выполнить 2 запроса (email, today), (email, yesterday) — в ответ придут логи, отсортированные по clustering key (то есть по времени).

              Вкратце, записи упорядочиваются в памяти и сбрасываются на диск линейно. За счет этого скорость записи максимальна (т.к. пишет последовательно), скорость чтения по ключу минимальна (по partition key Кассандра строит индекс, а так как данные хранятся в сортированном виде, то чтение тоже линейно).
                0
                Я неверно выразился. Имелось в виду, что касандра + map reduce не позволяет искать мгновенно. В вашем предложении не понятно, каким образом данные пользователя будут компактифицироваться и всегда находиться рядом. Если вы имеете в виду такую же компактификацию, которая есть в нашем решении, то ваше предложение звучит для меня как-то так: «Почему бы вам не сделать то же самое, заменив тарантул на кассандру». Я правильно понял, или что-то упускаю? :)
                  0
                  Наверное, вы делаете то же самое, что и мы, но используете свой тарантул вместо кассандры.
                  Упустил из виду, что у вас есть свое хранилише — думал, вы разработали тарантул специально под задачу.

                  А про кассандру, она в памяти группирует данные по partition ключам, плюс сортирует по clustering ключам. Сбрасывает на диск периодически, причем пишет последовательно. Поиск происходит быстро: по индексу находится адрес в файле на диске, далее последовательно читаются данные, которые всегда отсортированы по второму ключу.

                  Ну и partition ключи раскидываются по нодам, плюс репликация — примерно так работает и Hazelcast.
                    0
                    А как она компактифицирует данные? Т.е. как она передвигает разбросанные по всему диску данные одного юзера в одно месте, чтобы поиск был без лишних сиков? Кажется, что она это не делает.
                      0
                      Делает datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_write_path_c.html?scroll=concept_ds_wt3_32w_zj__dml-compaction

                      В новых версиях этот процесс они еще более улучшили, называется leveled compaction — он как раз для случая, когда запись часто апдейтят www.datastax.com/dev/blog/when-to-use-leveled-compaction

                      На всякий случай — каждый апп пишет логи в кассандру, а не в локальный файл.
                      Каждая запись выглядит как (key, value) — в вашем случае это может быть email и все остальное.
                      И кассандра уже занимается хранением, группировкой и сортировкой.
                        +1
                        Вы сейчас про то, что SSTable не изменяется, и ее надо перестраивать. Это да. Но если это делать постоянно с максимальной нагрузки на диски (как это делаем мы, как раз для экономии памяти — в терминах кассандры memtable), то использование кассандры тут — слишком тяжелое решение (т.е. кассандра не предполагает, что у вас настолько мало оперативной памяти, что диски загружены перестроением SSTable'ов на полную катушку). К тому же там внутри нет кластеризации (т.е. ее можно нашлепать только снаружи от движка кассандры). Т.е. перестроение SSTable происходит в рамках одного сервера. А у нас при компактификации каждый заново сформированный набор данных одного юзера записывается на рандомную пару серверов.
                        Кстати, спасибо, что начали эту дискуссию на эту тему, всегда приятно общаться с человеком, который хорошо разбирается в системах хранения!
                          0
                          Да, кассандра мержит таблицы внутри одного сервера (плюс все реплики). Но это из-за модели хранения — каждой ноде назначается свой диапазон 128 битного числа, но суммарно они покрывают 128 бит. Когда ключ пишется в кассандру, вычисляется 128 битный хэш, и по этому хэшу определяется нода (и все реплики), далее запись идет уже на конкретные ноды.

                          Чтение, кстати, может быть параллельным: если фактор репликации равен 3, то чтение будет происходить параллельно с 3 нод.
            +5
            а чем не подошёл splunk? он вроде бы решает именно эту задачу
              0
              Ровно такой же аргумент как и про Кассандру. Не позволяет искать мгновенно.
              +5
              Добавлю до кучи Logstash, с обвесом из Elasticsearch и Kibana счас в самом тренде…
                +1
                Надо понимать, что современные системы логирования и поиска по логам потенциально внутри устроены двумя способами: либо map reduce (фактически, это распределение запроса на поиск по большому количеству дисков), либо поверх какой-нибудь базы данных (а это означает SSD диски и на порядок более дорогое решение по железу, что для нашего петабайта логов выглядит уже существенным).
                  +5
                  Не совсем map-reduce в чистом виде.
                  Как я понял из вашей схемы тарантул только знает где лежат логи конкретного пользователя (какая машина, какой файл) и роутит запрос уже туда. То есть запрос идет не на все машины которые хранят логи, а только в конкретные машины и конктерные файлы данного пользователя. То есть это роутинг в чистом виде, а что там как лежит (в файле, в БД, в индексе Lucene) это уже не так важно.

                  В ElasticSearch есть и роутинг и алиасы для решения точно таких же задач.

                  Но при этом возможностей поиска и различных аггрегаций там конечно на порядок больше. К примеру вы хотите сделать запрос типа «Покажите мне количество ошибок которые содержат IndexOutOfBoundsException для пользователей в адресе который есть *hotmail.com, с разбивкой по часам за последние 2 дня». Вот я писал небольшую статью ElasticSearch 1.0 — новые возможности аналитики. А по объемам — есть очень крупные внедрения еластика.
                    +2
                    Тут основная сложность не в роутинге, а в компактификации. Данные пользователя должны быть всегда расположены рядом на диске, поэтому происходит постоянное перестроение всех данных. Таким образом, данные пользователя — это маленький кусок в памяти (который еще предстоит записать на диск в процессе перестроения) и исторический кусок на диске, расположенный строго последовательно. Эта технология позволяет и писать линейно и читать быстро. Т.е. у нас не map reduce, у нас нечто новое, и об этом мы как раз и захотели с вами поделиться :)
                      +1
                      Тогда это круто )
                        +2
                        По сути просто решение «заточенное» под задачу. В случае mail.ru вполне оправданно со всеми вытекающими затратами и преимуществами. В случае компаний поменьше поддерживаю tas и Cher с предложением elasticsearch. Как раз про такое решение в кластере скоро буду делать доклад на CEE Secr 2014
                          +1
                          Да, вы правы. Наша задача была хранить петабайт-два логов, иметь по ним быстрый поиск и при этом не разориться на серверах
                            0
                            Вот собственно и доклад про Elasticsearch/Logstash/Kibana
                            0
                            нечто новое

                            Ну не совсем новое, мы выше обсуждали, кассандра так умеет с самого начала — с 2008 года :)
                              0
                              У нас новость именно в простоте и заточке конкретно под конкретный паттерн, т.е. под хранение логов и быстрый поиск по ним.
                              Например, у нас нет distributed hash ring. И при этом абсолютная прозрачность в добавлении и удалении железа. Т.е. в эту систему можно добавлять сервера или вынимать из нее сервера, все при этом будет работать и без лишнего ребалансинга. Ну и внутри она устроена так, что позволяет почти бесконечно расти + выдерживает почти любые нагрузки на запись.
                              Т.е. еще раз — перестроение целиком всех данных и получение за счет этого быстрой записи и быстрого чтения — эта идея старая, идет еще от гуглового Big Table. Новое тут то, что она специфично заточена под логи, и из-за этого устроена на порядке проще, например, кассандры, и работает при этом сильно быстрее.
                      +1
                      Какая область применения вашей системы?
                      Я правильно понимаю, что вы её делали для службы поддержки или возможно другие варианты использования?
                        0
                        Для службы поддержки, для безопасников, для адинов, для разработчиков (админы и разработчики тоже туда смотрят, т.к. самые сложные проблемы решаются на их уровне, а не на уровне службы поддержки).
                          0
                          Аналитику по пользователям вы на основе этих же данных строите?
                            0
                            Нет. Для этого у нас отдельная система. Там уже база данных, SSD, олап-кубы и прочие пироги. И в ней мы храним не петабайт, а гораздо-гораздо меньше.
                            Эта же система, про которую статья, она как раз наоборот для хранения вообще всего по пользователю, чтобы потом, случай чего, можно было бы быстро понять, в чем проблема именно у конкретного пользователя.
                              0
                              Да, теперь картина полнее :)

                              Вопрос был задан потому, что существует классическая проблема: как посчитать аналитику по какому-нибудь параметру, который у нас есть в логах, но его совсем недавно стали пихать в базу аналитики.

                              У вас ответ: «система это не позволяет». Ок :) Ответ понятен :)
                                0
                                Во! И как раз для этого у нас в этой системе хранятся логи за все время. Мы, если надо, можем их из нее вынуть и загрузить в olap cube + можем все новое, что надо посылать в olap cube.
                                  0
                                  Понятно, да :) Это будет не так супер-быстро, как поиск по конкретному пользователю, но данные, всё же, будут.
                                    0
                                    Именно так. А в рамках системы, описываемой в посте, нам надо именно по конкретному юзеру искать супербыстро. Т.е. даже минуту это долго, потому что когда сотрудник техподдержки/админ/разработчик ждет минуту ответа от системы, то он теряет эту драгоценную минуту своей жизни за зря, и таких минут накапливается много :)
                          0
                          Для быстрого поиска Вас спец. службами :-)
                          0
                          На каждого пользователя отдельный файл, или логи нескольких пользователей могут храниться в одном файле?
                            0
                            Нет, конечно. Если бы был отдельный файл на пользователя, то система бы просто не работала. У нас суточная аудитория 20 миллионов человек, а месячная — 100 миллионов. У нас всего несколько файлов на диск. И логи пользователей хранятся в файле подряд линейными кусками.
                              0
                              Что происходит со старой информацией, когда из Tarantool приходит новая информация? Она затирается или остается как есть? Если затирается, то происходит ли потом дефрагментация?
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Что происходит с данными, которые демон взял для пользователя из файла?
                                  Они стираются? Если да, то происходит ли затем переиспользование этой памяти, какая-нибудь дефрагментация? Если не происходит и не затирается, то в файле должно быть колоссальное дублирование информации о каждом пользователе.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Спасибо за статью. Интересует процесс перезаписи файлов данных: вы пишете что их всего несколько, что, учитывая размер дисков, означает что эти файлы очень большие. Честное уплотнение требует полностью переписать файл что крайне затратно. Вопрос — вы только прикрепляете к концу полностью историю пользователя заново (оставляя ее части внутри) отпроцессировав весь файл? Или все-таки процессируете целиком? Сколько тогда времени такое обновление занимает?
                              0
                              Мы перезаписываем весь файл целиком. Фактически, эта система постоянно перезаписывает все. Делает она это со скоростью порядка 50Мб/с на чтение и столько же на запись. Как известно, скорость линейной чтении/записи SATA диска порядка 100Мб/с.Т.е. мы для фонового процесса используем 50% disk utilization, чтобы диски могли бы обрабатывать и запросы на чтение и дозапись новых данных.

                              Мы сейчас используем диски 4Тб (планируем переходить на 6Тб). 4Тб / 50Мб == 80К. Т.е. перезапись целиком занимает сутки. Вы можете спросить, куда так гнать, зачем раз в сутки? Ответ простой: мы обязаны держать в памяти копию всех новых данных пока эти данные не будут перезаписаны, если бы мы этого не делали, то поиск по последним данным приводил бы к фулскану по диску. Чем быстрее мы будем перезаписывать, тем меньше системе потребуется памяти.
                              0
                              А чем не подошел HBase? Его же можно индексировать. Вот тебе и доступ по ключу и поиск.
                                0
                                Мы тестировали HBase в другом нашем проекте, и она не потянула даже гораздо меньшие нагрузки.
                                  0
                                  Не потянула на запись или чтение? А метрики остались?
                                    0
                                    Не тянула на запись + работала не стабильно. Метрики вот так сходу не найду, но поищу.
                                      0
                                      Напрямую писали? Я не видел фичи поиска online, понял, что вам надо быстро искать по накопленным данным. Пробовали копить данные час-два-сутки и делать BulkLoad в HBase в обход WAL?
                                      Не стабильно — а как это проявлялось?
                                        0
                                        Я всех деталей уже не помню, было давно :) Но я обязательно подниму информацию.
                                        Копить часа два мы не можем — у нас все в онлайне. И опять же, остается вопрос насчет быстрой выборки. HBase хоть и индексирует данные, но он не дает гарантирю, что все данные одного юзера (т.е. все значения заданного ключа) будут лежать на диске подряд.
                                0
                                А если нужно погрепать по другому ключу — не по юзеру, а скажем по ip?
                                  0
                                  Тогда можно завести IPшник как ключ и дублировать в него всю ту же инфу, которая пишется по юзеру. Но на практике без привязки к юзеру нам такое редко надо, т.е. справляемся старым добрым грепом.
                                  0
                                  А у меня есть вкусный сочный кучек мяса, который я нежно обжарил на грилле и от него разносится восхитительный запах… Но тебе я его не дам.

                                  Вот так примерно выглядит ваш пост без ссылок на сырцы.
                                    +1
                                    Мы планируем привести их в порядок, зафиксить кое-какие баги, и далее, возможно, выложим в аутсорс.
                                      –1
                                      Вот тогда и приходите. А пока это хвастовство. А меня в детстве бабушка за то, что я шоколадной медалькой во дворе похвастался, но ни с кем ей не поделился, без оной шоколадки и оставила.
                                        +5
                                        Но от этого поста тоже есть польза. Вы узнали об архитектуре решения. Если есть вопросы, можем рассказать подробней. Согласитесь, если архитектура понятна и проста, то и исходники не нужны — можно все самому повторить.
                                    +2
                                    Здравствуйте.
                                    Некоторых проблем можно было бы избежать.
                                    К примеру, часто звучит вопрос о том, что в папке Входящие нет писем и/или уведомлений из сообществ. В большинстве случаев отсутствующие письма находятся в папке Спам. Попадать они туда могут случайно, когда вместо «Удалить» пользователь кликает на кнопку «Спам». Кнопки расположены рядом и ошибиться не сложно:
                                    image
                                    Второй вариант попадания уведомлений из сообществ в папку Спам, когда пользователь пытается отписаться от комментариев одного конкретного пользователя, и отправляет в спам все уведомления из мира, которые приходят с адреса myadmin@corp.mail.ru.
                                    Если бы разместить кнопки «Удалить» и «Спам» дальше друг от друга и добавить предупреждение, которое появляется при попытке отправить в спам уведомления из Мира, думаю, такие проблемы возникали бы реже.
                                      0
                                      Я правильно понимаю, что в конечном итоге это обратный индекс, применяемый в поисковых системах?
                                        0
                                        Нет. Тут совсем другая архитектура. Обратный индекс — это или B+ дерево или простой хэш в памяти типа word -> list of document ids.
                                          0
                                          Это техническая реализация. Я про идею, вместо списка слов емейлы. Хотел узнать, идейно так или еще сами логи реорганизуются чтобы юзер не был разбросан везде?
                                            0
                                            Идейно все ровно так как написано в посте. Могу повторить: новые данные пишутся в лог и в память. Читаются из памяти и из последовательного куска на диске (который в начале работы системы отсутствует). Все диски постоянно фулсканятся и данные перезаписываются из памяти и с диска так, чтобы опять создавать последовательный кусок для каждого юзера.
                                        0
                                        Жёсткие диски могут линейно записывать информацию со скоростью около 100 Мбит/сек.

                                        Какие-то древние у вас диски )
                                          0
                                          Обычные SATA-диски. Речь в статье о том, как придумать технологию, позволяющее решать задачу по хранению и доступа к большому количеству логов, с использованием самого дешевого per byte железа.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое