LinkedIn открыл (https://engineering.linkedin.com/pinot/open-sourcing-pinot-s... исходные тексты хранилища Pinot, ориентированного на выполнение аналитических запросов. Хранилище ориентировано (https://github.com/linkedin/pinot/wiki) на работу в условиях постоянного добавления новых данных (изменение уже сохранённой информации не поддерживается) и рассчитано на обеспечение минимальной задержки между добавлением данных и их обработки в реальном времени. Данные в хранилище могут загружаться из разных источников, начиная Hadoop и обычных файлов и заканчивая загрузки информации из online-источников, таких как Kafka. Код проекта написан на Java и распространяется (https://github.com/linkedin/pinot) под лицензией Apache.
Заявлено обеспечение горизонтальной масштабируемости и возможность хранения огромных объёмов данных. Например, в LinkedIn в Pinot хранится около ста миллирдов записей и ежедневно добавляется более миллиарда новых записей. Ежедневно выполняется около 100 миллионов аналитических запросов, интенсивность которых доходит до тысяч запросов в секунду. Отзывчивость при выполнении запросов составляет около 10 мс. Pinot используется в LinkedIn уже два года и лежит в основе реализации более 25 клиентских и 30 внутренних сервисов, таких как предоставление данных о пользователях посмотревших профиль и сообщения.
В системе предусмотрены средства обеспечения отказоустойчивости и сохранения живучести при возникновении программных и аппаратных ошибок. Pinot подразумевает встраивание репликации и резервного копирования непосредственно в цикл обработки добавляемых в хранилище данных. С одной стороны такой подход приводит к значительному упрощению архитектуры (https://github.com/linkedin/pinot/wiki/Architecture), но, с другой стороны, приводит к возникновению секундной задержки между добавлением данных и их доступностью для запросов. Для управления Pinot-кластером применяется Apache Helix (http://helix.apache.org/).
Обращение к хранилищу производится через привычный SQL-подобный интерфейс, поддерживающий типовые операции фильтрации выборки, агрегирования, сортировки и группировки данных. Для обеспечения предсказуемого времени выполнения запроса операции слияния таблиц (JOIN) не поддерживаются. Данные размещаются в таблицах базы данных, ориентированной на столбцы (column-oriented (https://en.wikipedia.org/wiki/Column-oriented_DBMS)). Поддерживаются различные схемы сжатия и возможность размещения нескольких значений в одном поле. Pinot предоставляет подключаемую систему индексов, в котором можно применять различные типы технологии индексации.<center><a href="https://github.com/linkedin/pinot/wiki/Architecture">... src="http://www.opennet.me/opennews/pics_base/0_1434214419.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: https://engineering.linkedin.com/pinot/open-sourcing-pinot-s...
Новость: http://www.opennet.me/opennews/art.shtml?num=42415
Интересно, сколько жабка кушает памяти на таких задачах.
Эластик например хочет 60% от хост памяти, залочить её(mlock) и неистово гонять.
до 200 миллионов документов на low end машине 4цпуХ8рамы будет вполне отзывчиво гонять поиском. С агрегацией уже будет по сложнее.
И он очень не любит конкурении по цпу с чем либо. Считаю, это довольно неплохой результат.
> Эластик например хочет 60% от хост памяти, залочить её(mlock) и неистово гонять.
> до 200 миллионов документов на low end машине 4цпуХ8рамы будет вполне отзывчиво
> гонять поиском. С агрегацией уже будет по сложнее.
> И он очень не любит конкурении по цпу с чем либо. Считаю,
> это довольно неплохой результат.спасибо
от хост-памяти
на "low end"-машине
будет посложнее
с чем-либо
Тут скорее нужно понимать с какого момента ваши задачи готовы к таким масштабам, если не готовы и не будут в принципе в будущем то в решения на яве не стоит ввязыватся. Либо покупать как сервис у кого-то.
Примерно столько же, сколько и сишечка. Оверхед от использования java-машины заметен только на мелких задачах.
Как смешно анон ты оверхед назвал незаметным. Спорить не буду про перформансы(это больная тема), только ты еще забыл добавить про хайпу и танцы со сборщиком мусора(дада, там это админ крутит) и xmx xms на каждом проекте. Jvm это не просто оверхед, это отдельная история которая затребует грамотный подход и некоторое количество возни.
Грамотный подход тут очень простой - как только становится важно "быстро" (и данных более-менее много), сборщик мусора сразу же идёт нафиг и начинаются те еще танцы вприсядку. Гуглить по словам off-heap, heap-offloading.
думаю, тут проблема не сборщике мусора как в таковом, а том, что существующие реализации сборщиков мусора не рассчитаны десятки/сотни гигабайт данных
Это звучит примерно как "проблема не в авиакрушениях как таковых, а в том, что существующие реализации самолетов не рассчитаны на выживание пассажиров при разваливании на части на высоте 10км"
> думаю, тут проблема не сборщике мусора как в таковом, а том, что
> существующие реализации сборщиков мусора не рассчитаны десятки/сотни гигабайт данныхКто виноват и что делать? ))
А если серьезно, до какого-то момента дело даже не в том что они(сборщики) не тянут, дело в кривом дизайне приложух. Ну т.е лид должен понимать под что они пишут, где там плюсы а где родовые травмы. Некоторые фракции разработчиков очень любят алгоритмы на доске и в презентации, как это реально будет работать их слабо волнует, считают что проблемы произвдительности надо решать масштабированием.
>Грамотный подход тут очень простой - как только становится важно "быстро" (и данных более-менее много), сборщик мусора сразу же идёт нафиг и начинаются те еще танцы вприсядку. Гуглить по словам off-heap, heap-offloading.Да знаем, это скорее решение вопроса в лоб со стороны админа. Актуально не только на жабке, похапе тоже иногда испытывает острую необходимость по работать без сборщика бесцельного бегающего по ссылкам пожирая цпу. (о великие мастера похаписты, избавьте нас в этом треде).
Админ, переписывающий Java-код? В какие интересные места вы ходите.
И пыхо/пистон код, по ситуации. Да, печалька.
Наоборот - веселуха! Постоянная, с утра и до утра, без выходных и праздников! :-)
> Примерно столько же, сколько и сишечка. Оверхед от использования java-машины заметен только на мелких задачах.Какую еще глупость вы нам расскажете?
> Примерно столько же, сколько и сишечка.Ну то-есть плюс-минус 10 гигз. Жабисты как-то так обычно меряют :)
Какая-то странная статистика: хранится 100 миллиардов записей, ежедневно добавляется более 1-го миллиарда. Если верить этой информации, то напрашиваются интересные выводы, как-то:- похоже, это хранилище в работе чуть дольше трёх месяцев (100 миллиардов / 1 миллиард в день = 100 дней),
- как это хранилище использовалось 19 месяцев до тех самых пресловутых трёх, если оно в работе уже целых два года,
- что же было до этого хранилища три месяца назад и почему же записи из старого хранилища не импортировали в новоеДаже перепроверил в оригинале - в переводе ошибки нет.
Возрастающая нагрузка? Убедились, что работает хорошо, и валят всё новые данные...
Или со временем агрегируют и сырые удаляют
Crazy Alex,вот я и говорю, какая-то странная статистика.
> Или со временем агрегируют и сырые удаляют
Думаете, "забыли" сказать, что регулярно удаляют записи
> Возрастающая нагрузка? Убедились, что работает хорошо, и валят всё новые данные...
или, что добавление чуть больше миллиарда записей в день происходит лишь последние две недели, а до этого было около 4.5 миллиардов в месяц или что-нибудь подобное?
Pinot is well suited for analytical use cases on immutable append-only data
Вместо обновления данных добавление по новой.
это же реклама, то есть содержание не ориентировано на считающих и думающих
"считающие и думающие" чаще обманывают самих себя, чем их обманывает какая-то реклама. ибо у каждого "считающего и думающего" обычно своя, единственно верная правда. :) правда, другие "считающие и думающие" с этим не согласны :)
только если допустить, что рост линейный
>> ежедневно добавляется более миллиарда новых записейУпор на слове __новых__
Я смотрю тебя не смущает, что хранятся "около ста миллирдов", а добавляются "более миллиарда".Речь в новости о разных единицах измерения.
Разве "100’s of billions" не переводится как "сотни миллиардов"?
> изменение уже сохранённой информации не поддерживаетсяДля кладбища логов многовато наворотов, имхо.
Ну так скучно ж просто спам-то рассылать, креатив просится наружу.
А MDX оно поддерживает?
Социалка, где каждый пишет какой он ох$$нный?
> Особая, офисная социалка, где каждый пишет какой он ох$$нный профессионал.Fixed.
