Комментарии 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 приходит новая информация? Она затирается или остается как есть? Если затирается, то происходит ли потом дефрагментация?
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью. Интересует процесс перезаписи файлов данных: вы пишете что их всего несколько, что, учитывая размер дисков, означает что эти файлы очень большие. Честное уплотнение требует полностью переписать файл что крайне затратно. Вопрос — вы только прикрепляете к концу полностью историю пользователя заново (оставляя ее части внутри) отпроцессировав весь файл? Или все-таки процессируете целиком? Сколько тогда времени такое обновление занимает?
Мы перезаписываем весь файл целиком. Фактически, эта система постоянно перезаписывает все. Делает она это со скоростью порядка 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 Мбит/сек.
Какие-то древние у вас диски )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как решать проблемы пользователей не за сутки, а за минуты: ускоряем поиск по логам