Comments 64
А где код? где ссылка на гитхаб? я так не играю. Поманили, вот у нас есть инструмент, а другим инструмент не дали, обидно.
А чем не подошла Cassandra? Там линейная запись на диск, но при этом упорядочивание по ключам.
Можно сделать составной ключ email + день + время, и получите то же самое.
Используем это подход для хранения наших логов со всех серверов.
Можно сделать составной ключ email + день + время, и получите то же самое.
Используем это подход для хранения наших логов со всех серверов.
смею предположить из-за того, что у них есть свой Tarantool.
Кассандра, как и прочие map reduce системы не позволяют искать мгновенное. Они лишь позволяют убыстрить этот процесс путем параллельных запросов по большому количеству дисков. Т.е. поиск среди 100Тб, распределенных по 100 дискам в map reduce системе будет занимать несколько часов. Это, конечно, быстрее, чем две недели, но все равно долго.
Кассандра — не map/reduce. Это тупое key-value хранилище, но зато очень быстрое, при правильной схеме.
В вашем случае я бы сделал partition key = email+day, clustering key = time
Кассандра ищет по ключу мгновенно. Значит, если нужны логи по конкретному пользователю за пару дней, нужно выполнить 2 запроса (email, today), (email, yesterday) — в ответ придут логи, отсортированные по clustering key (то есть по времени).
Вкратце, записи упорядочиваются в памяти и сбрасываются на диск линейно. За счет этого скорость записи максимальна (т.к. пишет последовательно), скорость чтения по ключу минимальна (по partition key Кассандра строит индекс, а так как данные хранятся в сортированном виде, то чтение тоже линейно).
В вашем случае я бы сделал partition key = email+day, clustering key = time
Кассандра ищет по ключу мгновенно. Значит, если нужны логи по конкретному пользователю за пару дней, нужно выполнить 2 запроса (email, today), (email, yesterday) — в ответ придут логи, отсортированные по clustering key (то есть по времени).
Вкратце, записи упорядочиваются в памяти и сбрасываются на диск линейно. За счет этого скорость записи максимальна (т.к. пишет последовательно), скорость чтения по ключу минимальна (по partition key Кассандра строит индекс, а так как данные хранятся в сортированном виде, то чтение тоже линейно).
Я неверно выразился. Имелось в виду, что касандра + map reduce не позволяет искать мгновенно. В вашем предложении не понятно, каким образом данные пользователя будут компактифицироваться и всегда находиться рядом. Если вы имеете в виду такую же компактификацию, которая есть в нашем решении, то ваше предложение звучит для меня как-то так: «Почему бы вам не сделать то же самое, заменив тарантул на кассандру». Я правильно понял, или что-то упускаю? :)
Наверное, вы делаете то же самое, что и мы, но используете свой тарантул вместо кассандры.
Упустил из виду, что у вас есть свое хранилише — думал, вы разработали тарантул специально под задачу.
А про кассандру, она в памяти группирует данные по partition ключам, плюс сортирует по clustering ключам. Сбрасывает на диск периодически, причем пишет последовательно. Поиск происходит быстро: по индексу находится адрес в файле на диске, далее последовательно читаются данные, которые всегда отсортированы по второму ключу.
Ну и partition ключи раскидываются по нодам, плюс репликация — примерно так работает и Hazelcast.
Упустил из виду, что у вас есть свое хранилише — думал, вы разработали тарантул специально под задачу.
А про кассандру, она в памяти группирует данные по partition ключам, плюс сортирует по clustering ключам. Сбрасывает на диск периодически, причем пишет последовательно. Поиск происходит быстро: по индексу находится адрес в файле на диске, далее последовательно читаются данные, которые всегда отсортированы по второму ключу.
Ну и partition ключи раскидываются по нодам, плюс репликация — примерно так работает и Hazelcast.
А как она компактифицирует данные? Т.е. как она передвигает разбросанные по всему диску данные одного юзера в одно месте, чтобы поиск был без лишних сиков? Кажется, что она это не делает.
Делает 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 и все остальное.
И кассандра уже занимается хранением, группировкой и сортировкой.
В новых версиях этот процесс они еще более улучшили, называется leveled compaction — он как раз для случая, когда запись часто апдейтят www.datastax.com/dev/blog/when-to-use-leveled-compaction
На всякий случай — каждый апп пишет логи в кассандру, а не в локальный файл.
Каждая запись выглядит как (key, value) — в вашем случае это может быть email и все остальное.
И кассандра уже занимается хранением, группировкой и сортировкой.
Вы сейчас про то, что SSTable не изменяется, и ее надо перестраивать. Это да. Но если это делать постоянно с максимальной нагрузки на диски (как это делаем мы, как раз для экономии памяти — в терминах кассандры memtable), то использование кассандры тут — слишком тяжелое решение (т.е. кассандра не предполагает, что у вас настолько мало оперативной памяти, что диски загружены перестроением SSTable'ов на полную катушку). К тому же там внутри нет кластеризации (т.е. ее можно нашлепать только снаружи от движка кассандры). Т.е. перестроение SSTable происходит в рамках одного сервера. А у нас при компактификации каждый заново сформированный набор данных одного юзера записывается на рандомную пару серверов.
Кстати, спасибо, что начали эту дискуссию на эту тему, всегда приятно общаться с человеком, который хорошо разбирается в системах хранения!
Кстати, спасибо, что начали эту дискуссию на эту тему, всегда приятно общаться с человеком, который хорошо разбирается в системах хранения!
Да, кассандра мержит таблицы внутри одного сервера (плюс все реплики). Но это из-за модели хранения — каждой ноде назначается свой диапазон 128 битного числа, но суммарно они покрывают 128 бит. Когда ключ пишется в кассандру, вычисляется 128 битный хэш, и по этому хэшу определяется нода (и все реплики), далее запись идет уже на конкретные ноды.
Чтение, кстати, может быть параллельным: если фактор репликации равен 3, то чтение будет происходить параллельно с 3 нод.
Чтение, кстати, может быть параллельным: если фактор репликации равен 3, то чтение будет происходить параллельно с 3 нод.
а чем не подошёл splunk? он вроде бы решает именно эту задачу
Добавлю до кучи Logstash, с обвесом из Elasticsearch и Kibana счас в самом тренде…
Надо понимать, что современные системы логирования и поиска по логам потенциально внутри устроены двумя способами: либо map reduce (фактически, это распределение запроса на поиск по большому количеству дисков), либо поверх какой-нибудь базы данных (а это означает SSD диски и на порядок более дорогое решение по железу, что для нашего петабайта логов выглядит уже существенным).
Не совсем map-reduce в чистом виде.
Как я понял из вашей схемы тарантул только знает где лежат логи конкретного пользователя (какая машина, какой файл) и роутит запрос уже туда. То есть запрос идет не на все машины которые хранят логи, а только в конкретные машины и конктерные файлы данного пользователя. То есть это роутинг в чистом виде, а что там как лежит (в файле, в БД, в индексе Lucene) это уже не так важно.
В ElasticSearch есть и роутинг и алиасы для решения точно таких же задач.
Но при этом возможностей поиска и различных аггрегаций там конечно на порядок больше. К примеру вы хотите сделать запрос типа «Покажите мне количество ошибок которые содержат IndexOutOfBoundsException для пользователей в адресе который есть *hotmail.com, с разбивкой по часам за последние 2 дня». Вот я писал небольшую статью ElasticSearch 1.0 — новые возможности аналитики. А по объемам — есть очень крупные внедрения еластика.
Как я понял из вашей схемы тарантул только знает где лежат логи конкретного пользователя (какая машина, какой файл) и роутит запрос уже туда. То есть запрос идет не на все машины которые хранят логи, а только в конкретные машины и конктерные файлы данного пользователя. То есть это роутинг в чистом виде, а что там как лежит (в файле, в БД, в индексе Lucene) это уже не так важно.
В ElasticSearch есть и роутинг и алиасы для решения точно таких же задач.
Но при этом возможностей поиска и различных аггрегаций там конечно на порядок больше. К примеру вы хотите сделать запрос типа «Покажите мне количество ошибок которые содержат IndexOutOfBoundsException для пользователей в адресе который есть *hotmail.com, с разбивкой по часам за последние 2 дня». Вот я писал небольшую статью ElasticSearch 1.0 — новые возможности аналитики. А по объемам — есть очень крупные внедрения еластика.
Тут основная сложность не в роутинге, а в компактификации. Данные пользователя должны быть всегда расположены рядом на диске, поэтому происходит постоянное перестроение всех данных. Таким образом, данные пользователя — это маленький кусок в памяти (который еще предстоит записать на диск в процессе перестроения) и исторический кусок на диске, расположенный строго последовательно. Эта технология позволяет и писать линейно и читать быстро. Т.е. у нас не map reduce, у нас нечто новое, и об этом мы как раз и захотели с вами поделиться :)
Тогда это круто )
По сути просто решение «заточенное» под задачу. В случае mail.ru вполне оправданно со всеми вытекающими затратами и преимуществами. В случае компаний поменьше поддерживаю tas и Cher с предложением elasticsearch. Как раз про такое решение в кластере скоро буду делать доклад на CEE Secr 2014
Да, вы правы. Наша задача была хранить петабайт-два логов, иметь по ним быстрый поиск и при этом не разориться на серверах
Вот собственно и доклад про Elasticsearch/Logstash/Kibana
нечто новое
Ну не совсем новое, мы выше обсуждали, кассандра так умеет с самого начала — с 2008 года :)
У нас новость именно в простоте и заточке конкретно под конкретный паттерн, т.е. под хранение логов и быстрый поиск по ним.
Например, у нас нет distributed hash ring. И при этом абсолютная прозрачность в добавлении и удалении железа. Т.е. в эту систему можно добавлять сервера или вынимать из нее сервера, все при этом будет работать и без лишнего ребалансинга. Ну и внутри она устроена так, что позволяет почти бесконечно расти + выдерживает почти любые нагрузки на запись.
Т.е. еще раз — перестроение целиком всех данных и получение за счет этого быстрой записи и быстрого чтения — эта идея старая, идет еще от гуглового Big Table. Новое тут то, что она специфично заточена под логи, и из-за этого устроена на порядке проще, например, кассандры, и работает при этом сильно быстрее.
Например, у нас нет distributed hash ring. И при этом абсолютная прозрачность в добавлении и удалении железа. Т.е. в эту систему можно добавлять сервера или вынимать из нее сервера, все при этом будет работать и без лишнего ребалансинга. Ну и внутри она устроена так, что позволяет почти бесконечно расти + выдерживает почти любые нагрузки на запись.
Т.е. еще раз — перестроение целиком всех данных и получение за счет этого быстрой записи и быстрого чтения — эта идея старая, идет еще от гуглового Big Table. Новое тут то, что она специфично заточена под логи, и из-за этого устроена на порядке проще, например, кассандры, и работает при этом сильно быстрее.
Какая область применения вашей системы?
Я правильно понимаю, что вы её делали для службы поддержки или возможно другие варианты использования?
Я правильно понимаю, что вы её делали для службы поддержки или возможно другие варианты использования?
Для службы поддержки, для безопасников, для адинов, для разработчиков (админы и разработчики тоже туда смотрят, т.к. самые сложные проблемы решаются на их уровне, а не на уровне службы поддержки).
Аналитику по пользователям вы на основе этих же данных строите?
Нет. Для этого у нас отдельная система. Там уже база данных, SSD, олап-кубы и прочие пироги. И в ней мы храним не петабайт, а гораздо-гораздо меньше.
Эта же система, про которую статья, она как раз наоборот для хранения вообще всего по пользователю, чтобы потом, случай чего, можно было бы быстро понять, в чем проблема именно у конкретного пользователя.
Эта же система, про которую статья, она как раз наоборот для хранения вообще всего по пользователю, чтобы потом, случай чего, можно было бы быстро понять, в чем проблема именно у конкретного пользователя.
Да, теперь картина полнее :)
Вопрос был задан потому, что существует классическая проблема: как посчитать аналитику по какому-нибудь параметру, который у нас есть в логах, но его совсем недавно стали пихать в базу аналитики.
У вас ответ: «система это не позволяет». Ок :) Ответ понятен :)
Вопрос был задан потому, что существует классическая проблема: как посчитать аналитику по какому-нибудь параметру, который у нас есть в логах, но его совсем недавно стали пихать в базу аналитики.
У вас ответ: «система это не позволяет». Ок :) Ответ понятен :)
Во! И как раз для этого у нас в этой системе хранятся логи за все время. Мы, если надо, можем их из нее вынуть и загрузить в olap cube + можем все новое, что надо посылать в olap cube.
Понятно, да :) Это будет не так супер-быстро, как поиск по конкретному пользователю, но данные, всё же, будут.
Именно так. А в рамках системы, описываемой в посте, нам надо именно по конкретному юзеру искать супербыстро. Т.е. даже минуту это долго, потому что когда сотрудник техподдержки/админ/разработчик ждет минуту ответа от системы, то он теряет эту драгоценную минуту своей жизни за зря, и таких минут накапливается много :)
Для быстрого поиска Вас спец. службами :-)
На каждого пользователя отдельный файл, или логи нескольких пользователей могут храниться в одном файле?
Нет, конечно. Если бы был отдельный файл на пользователя, то система бы просто не работала. У нас суточная аудитория 20 миллионов человек, а месячная — 100 миллионов. У нас всего несколько файлов на диск. И логи пользователей хранятся в файле подряд линейными кусками.
Что происходит со старой информацией, когда из Tarantool приходит новая информация? Она затирается или остается как есть? Если затирается, то происходит ли потом дефрагментация?
UFO just landed and posted this here
Спасибо за статью. Интересует процесс перезаписи файлов данных: вы пишете что их всего несколько, что, учитывая размер дисков, означает что эти файлы очень большие. Честное уплотнение требует полностью переписать файл что крайне затратно. Вопрос — вы только прикрепляете к концу полностью историю пользователя заново (оставляя ее части внутри) отпроцессировав весь файл? Или все-таки процессируете целиком? Сколько тогда времени такое обновление занимает?
Мы перезаписываем весь файл целиком. Фактически, эта система постоянно перезаписывает все. Делает она это со скоростью порядка 50Мб/с на чтение и столько же на запись. Как известно, скорость линейной чтении/записи SATA диска порядка 100Мб/с.Т.е. мы для фонового процесса используем 50% disk utilization, чтобы диски могли бы обрабатывать и запросы на чтение и дозапись новых данных.
Мы сейчас используем диски 4Тб (планируем переходить на 6Тб). 4Тб / 50Мб == 80К. Т.е. перезапись целиком занимает сутки. Вы можете спросить, куда так гнать, зачем раз в сутки? Ответ простой: мы обязаны держать в памяти копию всех новых данных пока эти данные не будут перезаписаны, если бы мы этого не делали, то поиск по последним данным приводил бы к фулскану по диску. Чем быстрее мы будем перезаписывать, тем меньше системе потребуется памяти.
Мы сейчас используем диски 4Тб (планируем переходить на 6Тб). 4Тб / 50Мб == 80К. Т.е. перезапись целиком занимает сутки. Вы можете спросить, куда так гнать, зачем раз в сутки? Ответ простой: мы обязаны держать в памяти копию всех новых данных пока эти данные не будут перезаписаны, если бы мы этого не делали, то поиск по последним данным приводил бы к фулскану по диску. Чем быстрее мы будем перезаписывать, тем меньше системе потребуется памяти.
А чем не подошел HBase? Его же можно индексировать. Вот тебе и доступ по ключу и поиск.
Мы тестировали HBase в другом нашем проекте, и она не потянула даже гораздо меньшие нагрузки.
Не потянула на запись или чтение? А метрики остались?
Не тянула на запись + работала не стабильно. Метрики вот так сходу не найду, но поищу.
Напрямую писали? Я не видел фичи поиска online, понял, что вам надо быстро искать по накопленным данным. Пробовали копить данные час-два-сутки и делать BulkLoad в HBase в обход WAL?
Не стабильно — а как это проявлялось?
Не стабильно — а как это проявлялось?
Я всех деталей уже не помню, было давно :) Но я обязательно подниму информацию.
Копить часа два мы не можем — у нас все в онлайне. И опять же, остается вопрос насчет быстрой выборки. HBase хоть и индексирует данные, но он не дает гарантирю, что все данные одного юзера (т.е. все значения заданного ключа) будут лежать на диске подряд.
Копить часа два мы не можем — у нас все в онлайне. И опять же, остается вопрос насчет быстрой выборки. HBase хоть и индексирует данные, но он не дает гарантирю, что все данные одного юзера (т.е. все значения заданного ключа) будут лежать на диске подряд.
А если нужно погрепать по другому ключу — не по юзеру, а скажем по ip?
А у меня есть вкусный сочный кучек мяса, который я нежно обжарил на грилле и от него разносится восхитительный запах… Но тебе я его не дам.
Вот так примерно выглядит ваш пост без ссылок на сырцы.
Вот так примерно выглядит ваш пост без ссылок на сырцы.
Здравствуйте.
Некоторых проблем можно было бы избежать.
К примеру, часто звучит вопрос о том, что в папке Входящие нет писем и/или уведомлений из сообществ. В большинстве случаев отсутствующие письма находятся в папке Спам. Попадать они туда могут случайно, когда вместо «Удалить» пользователь кликает на кнопку «Спам». Кнопки расположены рядом и ошибиться не сложно:
Второй вариант попадания уведомлений из сообществ в папку Спам, когда пользователь пытается отписаться от комментариев одного конкретного пользователя, и отправляет в спам все уведомления из мира, которые приходят с адреса myadmin@corp.mail.ru.
Если бы разместить кнопки «Удалить» и «Спам» дальше друг от друга и добавить предупреждение, которое появляется при попытке отправить в спам уведомления из Мира, думаю, такие проблемы возникали бы реже.
Некоторых проблем можно было бы избежать.
К примеру, часто звучит вопрос о том, что в папке Входящие нет писем и/или уведомлений из сообществ. В большинстве случаев отсутствующие письма находятся в папке Спам. Попадать они туда могут случайно, когда вместо «Удалить» пользователь кликает на кнопку «Спам». Кнопки расположены рядом и ошибиться не сложно:
Второй вариант попадания уведомлений из сообществ в папку Спам, когда пользователь пытается отписаться от комментариев одного конкретного пользователя, и отправляет в спам все уведомления из мира, которые приходят с адреса myadmin@corp.mail.ru.
Если бы разместить кнопки «Удалить» и «Спам» дальше друг от друга и добавить предупреждение, которое появляется при попытке отправить в спам уведомления из Мира, думаю, такие проблемы возникали бы реже.
Я правильно понимаю, что в конечном итоге это обратный индекс, применяемый в поисковых системах?
Нет. Тут совсем другая архитектура. Обратный индекс — это или B+ дерево или простой хэш в памяти типа word -> list of document ids.
Это техническая реализация. Я про идею, вместо списка слов емейлы. Хотел узнать, идейно так или еще сами логи реорганизуются чтобы юзер не был разбросан везде?
Идейно все ровно так как написано в посте. Могу повторить: новые данные пишутся в лог и в память. Читаются из памяти и из последовательного куска на диске (который в начале работы системы отсутствует). Все диски постоянно фулсканятся и данные перезаписываются из памяти и с диска так, чтобы опять создавать последовательный кусок для каждого юзера.
Жёсткие диски могут линейно записывать информацию со скоростью около 100 Мбит/сек.
Какие-то древние у вас диски )
Sign up to leave a comment.
Как решать проблемы пользователей не за сутки, а за минуты: ускоряем поиск по логам