The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

LinkedIn открыл код распределённого OLAP-хранилища Pinot

13.06.2015 19:49

LinkedIn открыл исходные тексты хранилища Pinot, предназначенного для выполнения аналитических запросов. Хранилище ориентировано на работу в условиях постоянного добавления новых данных (изменение уже сохранённой информации не поддерживается) и рассчитано на обеспечение минимальной задержки и возможности их обработки в реальном времени. Данные в хранилище могут загружаться из разных источников, начиная Hadoop и обычных файлов и заканчивая получением информации от online-источников, таких как Kafka. Код проекта написан на Java и распространяется под лицензией Apache.

Заявлено обеспечение горизонтальной масштабируемости и возможность хранения огромных объёмов данных. Например, в LinkedIn в Pinot хранится около ста миллирдов записей и ежедневно добавляется более миллиарда новых записей. Ежедневно выполняется около 100 миллионов аналитических запросов, интенсивность которых доходит до тысяч запросов в секунду. Отзывчивость при выполнении запросов составляет около 10 мс. Pinot используется в LinkedIn уже два года и лежит в основе реализации более 25 клиентских и 30 внутренних сервисов, таких как предоставление данных о пользователях посмотревших профиль и сообщение.

В системе предусмотрены средства обеспечения отказоустойчивости и сохранения живучести при возникновении программных и аппаратных ошибок. Pinot подразумевает встраивание репликации и резервного копирования непосредственно в цикл обработки добавляемых в хранилище данных. С одной стороны такой подход позволяет значительно упростить архитектуру, но, с другой стороны, приводит к возникновению секундной задержки между добавлением данных и их доступностью для запросов. Для управления Pinot-кластером применяется Apache Helix.

Обращение к хранилищу производится через привычный SQL-подобный интерфейс, поддерживающий типовые операции фильтрации выборки, агрегирования, сортировки и группировки данных. Для обеспечения предсказуемого времени выполнения запроса не поддерживаются операции слияния таблиц (JOIN). Данные размещаются в таблицах базы данных, ориентированной на столбцы (column-oriented). Поддерживаются различные схемы сжатия и возможность размещения нескольких значений в одном поле. Pinot предоставляет подключаемую систему индексов, в которой можно применять различные технологии индексации.



  1. Главная ссылка к новости (https://engineering.linkedin.c...)
  2. OpenNews: Выпуск распределённого отказоустойчивого хранилища LeoFS 1.1.2
  3. OpenNews: Основатели ClamAV представили LibreS3, открытую реализацию хранилища Amazon S3
  4. OpenNews: Facebook открыл код распределённого SQL-движка для петабайтных хранилищ
  5. OpenNews: Открыты исходные тексты БД Aerospike
  6. OpenNews: Выпуск СУБД RethinkDB 2.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42415-pinot
Ключевые слова: pinot
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:55, 13/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Интересно, сколько жабка кушает памяти на таких задачах.
     
     
  • 2.5, username (??), 20:40, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Эластик например хочет 60% от хост памяти, залочить её(mlock) и неистово гонять.
    до 200 миллионов документов на low end машине 4цпуХ8рамы будет вполне отзывчиво гонять поиском. С агрегацией уже будет по сложнее.
    И он очень не любит конкурении по цпу с чем либо. Считаю, это довольно неплохой результат.
     
     
  • 3.8, Аноним (-), 21:00, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Эластик например хочет 60% от хост памяти, залочить её(mlock) и неистово гонять.
    > до 200 миллионов документов на low end машине 4цпуХ8рамы будет вполне отзывчиво
    > гонять поиском. С агрегацией уже будет по сложнее.
    > И он очень не любит конкурении по цпу с чем либо. Считаю,
    > это довольно неплохой результат.

    спасибо

     
  • 3.30, GrammarNarziss (?), 11:04, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    от хост-памяти
    на "low end"-машине
    будет посложнее
    с чем-либо
     
  • 2.6, username (??), 20:47, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут скорее нужно понимать с какого момента ваши задачи готовы к таким масштабам, если не готовы и не будут в принципе в будущем то в решения на яве не стоит ввязыватся. Либо покупать как сервис у кого-то.
     
  • 2.10, Аноним (-), 21:33, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Примерно столько же, сколько и сишечка. Оверхед от использования java-машины заметен только на мелких задачах.
     
     
  • 3.11, username (??), 22:46, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как смешно анон ты оверхед назвал незаметным. Спорить не буду про перформансы(это больная тема), только ты еще забыл добавить про хайпу и танцы со сборщиком мусора(дада, там это админ крутит) и xmx xms на каждом проекте. Jvm это не просто оверхед, это отдельная история которая затребует грамотный подход и некоторое количество возни.
     
     
  • 4.19, rob pike (?), 09:52, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Грамотный подход тут очень простой - как только становится важно "быстро" (и данных более-менее много), сборщик мусора сразу же идёт нафиг и начинаются те еще танцы вприсядку. Гуглить по словам off-heap, heap-offloading.
     
     
  • 5.21, Аноним (-), 10:37, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    думаю, тут проблема не сборщике мусора как в таковом, а том, что существующие реализации сборщиков мусора не рассчитаны десятки/сотни гигабайт данных
     
     
  • 6.24, rob pike (?), 16:53, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это звучит примерно как "проблема не в авиакрушениях как таковых, а в том, что существующие реализации самолетов не рассчитаны на выживание пассажиров при разваливании на части на высоте 10км"
     
  • 6.27, username (??), 22:24, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > думаю, тут проблема не сборщике мусора как в таковом, а том, что
    > существующие реализации сборщиков мусора не рассчитаны десятки/сотни гигабайт данных

    Кто виноват и что делать?  ))
    А если серьезно, до какого-то момента дело даже не в том что они(сборщики) не тянут, дело в кривом дизайне приложух. Ну т.е лид должен понимать под что они пишут, где там плюсы а где родовые травмы. Некоторые фракции разработчиков очень любят алгоритмы на доске и в презентации, как это реально будет работать их слабо волнует, считают что проблемы произвдительности надо решать масштабированием.  

     
  • 5.26, username (??), 22:15, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Грамотный подход тут очень простой - как только становится важно "быстро" (и данных более-менее много), сборщик мусора сразу же идёт нафиг и начинаются те еще танцы вприсядку. Гуглить по словам off-heap, heap-offloading.

    Да знаем, это скорее решение вопроса в лоб со стороны админа. Актуально не только на жабке, похапе тоже иногда испытывает острую необходимость по работать без сборщика бесцельного бегающего по ссылкам пожирая цпу. (о великие мастера похаписты, избавьте нас в этом треде).

     
     
  • 6.32, rob pike (?), 11:33, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Админ, переписывающий Java-код? В какие интересные места вы ходите.

     
     
  • 7.33, username (??), 12:09, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И пыхо/пистон код, по ситуации. Да, печалька.
     
     
  • 8.38, Аноним (-), 16:14, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот - веселуха Постоянная, с утра и до утра, без выходных и праздников -... текст свёрнут, показать
     
  • 3.14, Аноним (-), 00:10, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Примерно столько же, сколько и сишечка. Оверхед от использования java-машины заметен только на мелких задачах.

    Какую еще глупость вы нам расскажете?

     
  • 3.35, Аноним (-), 14:44, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Примерно столько же, сколько и сишечка.

    Ну то-есть плюс-минус 10 гигз. Жабисты как-то так обычно меряют :)

     

  • 1.9, Ярослав (??), 21:32, 13/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какая-то странная статистика: хранится 100 миллиардов записей, ежедневно добавляется более 1-го миллиарда. Если верить этой информации, то напрашиваются интересные выводы, как-то:

    - похоже, это хранилище в работе чуть дольше трёх месяцев (100 миллиардов / 1 миллиард в день = 100 дней),
    - как это хранилище использовалось 19 месяцев до тех самых пресловутых трёх, если оно в работе уже целых два года,
    - что же было до этого хранилища три месяца назад и почему же записи из старого хранилища не импортировали в новое

    Даже перепроверил в оригинале - в переводе ошибки нет.

     
     
  • 2.12, Crazy Alex (ok), 23:35, 13/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Возрастающая нагрузка? Убедились, что работает хорошо, и валят всё новые данные...
    Или со временем агрегируют и сырые удаляют
     
     
  • 3.17, Ярослав (??), 00:16, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Crazy Alex,

    вот я и говорю, какая-то странная статистика.

    > Или со временем агрегируют и сырые удаляют

    Думаете, "забыли" сказать, что регулярно удаляют записи

    > Возрастающая нагрузка? Убедились, что работает хорошо, и валят всё новые данные...

    или, что добавление чуть больше миллиарда записей в день происходит лишь последние две недели, а до этого было около 4.5 миллиардов в месяц или что-нибудь подобное?

     
  • 2.13, Аноним (-), 00:07, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Pinot is well suited for analytical use cases on immutable append-only data
    Вместо обновления данных добавление по новой.
     
  • 2.16, Аноним (-), 00:12, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    это же реклама, то есть содержание не ориентировано на считающих и думающих
     
     
  • 3.18, бедный буратино (ok), 06:07, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    "считающие и думающие" чаще обманывают самих себя, чем их обманывает какая-то реклама. ибо у каждого "считающего и думающего" обычно своя, единственно верная правда. :) правда, другие "считающие и думающие" с этим не согласны :)
     
  • 2.22, Нанобот (ok), 10:39, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    только если допустить, что рост линейный
     
     
  • 3.28, Есюки (?), 08:47, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> ежедневно добавляется более миллиарда новых записей

    Упор на слове __новых__

     
     
  • 4.39, клоун (?), 16:29, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Я смотрю тебя не смущает, что хранятся "около ста миллирдов", а добавляются "более миллиарда".

    Речь в новости о разных единицах измерения.

     
  • 2.29, Anonon (?), 09:49, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разве "100’s of billions" не переводится как "сотни миллиардов"?
     

  • 1.15, YetAnotherOnanym (ok), 00:11, 14/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > изменение уже сохранённой информации не поддерживается

    Для кладбища логов многовато наворотов, имхо.

     
     
  • 2.20, rob pike (?), 09:54, 14/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так скучно ж просто спам-то рассылать, креатив просится наружу.

     

  • 1.25, anonymous (??), 17:40, 14/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А MDX оно поддерживает?
     
  • 1.31, Зенитарка (?), 11:22, 15/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Социалка, где каждый пишет какой он ох$$нный?
     
     
  • 2.34, YetAnotherOnanym (ok), 12:47, 15/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Особая, офисная социалка, где каждый пишет какой он ох$$нный профессионал.

    Fixed.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру