Pull to refresh
23
0
Demeter Sztanko @sztanko

Big Data Architect

Send message

Извините за задержку с ответом. Но постараюсь ещё в этом году.


Ваши расчёты правильны, но боюсь, мы по разному понимаем терминологию. В нашем случае под кубом мы как раз понимаем N-мерное пространство, в котором есть точки. Таких пространств у нас как раз 300, и каждое из них есть некоторая фильтрация и проекция изначальных данных. Так, события нажатия на кнопку попадают в основной куб нажатий на кнопку, главный куб всех событий, и ещё несколько специфических кубов. Во всех случаях в кубы попадают только некоторые проекции этого события, каждый раз разные. Размерность каждого куба варьируеться от 12 до 30, и суммарное количество всех точек во всех кубах есть 500 000 000. К сожалению, кубы совсем незаполнены, как пространство. Согласен, что если бы дело обстояло иначе, КПД можно было бы увеличить, но с другой стороны, появились бы новые проблемы, как например, потребность переадрессации при изменении количества елементов в любом из измерений.


Я надеюсь, этот комментарий вносит больше ясности. И с Новым Годом вас!

Спасибо за ваш комментарий. Конечно, что считаем мы количество уникальных активных точек, а не входных данных. Неуникальных событий, которые приводят к инкременту, у нас около 12 миллиардов в день.
У нас есть две разбивки — по часам и по дням. У каждой из разбивок 300 кубов, и счётчики хранятся 90 часов и дней соответственно. Все вместе это набирает уже больше, чем 500 000 000 точек.

Нет. Для нас это не было требованием.

Отчеты, для которых был создан CubeDB, в основном конфиденциальны и работают только в корпоративном интранете. Ими пользуется от силы сто человек в день. Это такой себе
high load навыворот — пользователей немного, но данных очень много. Теоретически, если база падает, то SystemD ее сразу запускает обратно. Загрузка данных с диска длится где-то 3 минуты, что для нас было бы позволительным.
За год пользования системой проблемы возникали только раз, из-за вышеупомянутого бага.

Если нам нужно перегрузить базу для обновления, мы оповещаем всех пользователей и стараемся это делать не в рабочее время.

Если бы вдруг возникло бы требование сделать систему отазоустойчивой, мы бы скорее всего просто бы запустили еще одну копию на другой машине и балансировали бы нагрузку стандартными инструментами.
Посмотрите хотя бы RocksDB.

Отбросим Tarantool, посмотрим на RocksDB. Вы, наверное, ссылаетесь вот на эту хитроумную особенность системы, которая была только предложена тогда, когда мы уже 6 месяцев, как использовали CubeDB. Раз мы уже там, предлагаю вам посмотреть на замеры, из которых следует, что RocksDB будет как минимум в два раза медленне для нашего сценария. Зато в RocksDB много захватывющей функциональности, которая в нашем случае совсем не нужна.

Полное отсуствие чисел и ссылок в комментариях делает выши мысли менее конструктивными, хотя они заслуживают большего. Я все еще был бы благодарен, если бы вы предложили свой вариант, с приблизительной оценкой производительности.

Теперь вы еще будете обязаны поддерживать свою систему, а это очень много времени.

Создание собственной системы — всегда рискованное предприятие. Но как раз тот факт, что за 14 месяцев пользования системой был обнаружен только один серьезный баг (да и тот — в коде third party library), подтверждает правильность выбора архтитекутры.

Запуск многих процессов одновременно, использование скриптовых надстроек, спорная производительность, отсуствие нужного функционала, использование неподходящей модели данных — мой опыт подсказывет, что все это маленькие сигналы к тому, что движение происходит в неправильном направлении кактуса, и скоро будет очень больно.

Ну а так, я согласен с вами: используя 48 пилочек и собственноручные насадки к ним можно искуссно забить гвоздь, не прибегая к молотку.
В первую очередь, требование #2 (Фильтровать по любой комбинации полей и по интервалу дат) и требование #3 (Представлять результаты в виде фасетов) довольно таки сложно эффективно реализовать с помощью даже таких навороченных KV хранилищ, как Tarantool. В нашем случае невозможно придумать ключ, по которому бы извлекались только нужные записи. Невозможно также заранее определить поля, по значениях которых будут фильтроваться записи перед суммированием, поэтому вторичная индексация не поможет. Поэтому, единственное решение в контексте KV хранилищ — написать процедуру на Lua, которая будет прочесывать все записи и суммировать результат. Но на одном процессоре производительность будет не та, даже если предположить, что Lua настолько же быстра, как и Java.

В теории, если расшардить данные на 48 процессов и так заставить работать все ядра, мы бы могли намного увеличить производительность. Должен сказать, что об этом мы не подумали и это довольно интересная идея. Но в любом случае, здесь слишком много предположений, которые еще нужно проверить и мне не кажутся реалистическими, как, например, скорость Lua. Для воплощения требований #4, #5 и #9 нужно будет писать дополнительную обертку, что усложняет систему.

В дополнение к этому всему, ни один из KV хранилищ не сжимает данные. 500 миллионов счетчиков в формате msgpack просто бы не поместились в память.
Сборщик мусора — который по умолчанию у Java 8. Тот, который параллельный.
Хочу все же приметить, что сложности в основном возникали, когда все 48 процессоров хотели зарезервироваиь себе память под короткоживущий обьект (HashMap), который отбрасывался сразу же после отдачи результата.
Использовать 48 процессов Tarantool одновременно- интересная идея, если я правильно понимаю, о чем вы.
Если вас не затруднит, не могли бы вы чуть более развернуто описать свое видение решения, базирующего на Tarantool и выполняющего все 10 требований, описанных в статье?
Все почти так, если наша задача — подсчитывать и показывать количество уникальных пользователей.
Но у нас задача еще проще — показывать абсолютное количество событий, и это всегда выражается одной цифрой, независимо от количества пользователей.
Проблема у нас не в количестве пользователей, а в количестве комбинаций разных параметров фильтрования. Их у нас сейчас около полмиллиарда, и количество их от увеличения числа пользователей не изменится.
Да, 3 дня делали POC на их кластере с 20-ью нодами. Тестировали те же запросы и на тех же данных, что и для Exasola.
+1 в «А не пробовали ?»: Kognitio

Это самая настоящая in-memory БД. То есть, данные там действительно должны влезать в физическую память, иначе она отказывается работать. Никаких индексов, все брутальный и быстрый фулл скан. По нашим оценкам, они превосходили скорость Exasolа в несколько раз. Но не скоростью единой живет человек, да и цена у них тоже сильно кусачая была, поэтому в итоге выбрали не их. Но если вам нужна как раз скорость, объем Data Warehouse не будет превосходить нескольких TB, и цена для вас не вопрос, то я бы рекомендовал присмотреться. У нас главным блокером был как раз фактор быстрого роста данных.
Оптимальное расположение меток — НП сложная задача (https://en.wikipedia.org/wiki/Automatic_label_placement) и по-хорошему решается имитацией отжига (https://github.com/migurski/Dymo). Между 2010 и 2016 Гугл ввел третью версию своих карт, которые базируются на векторных данных и рендерят уже на клиенте. Я уверен, что это и есть главной причиной таких изменений.

Information

Rating
Does not participate
Location
England - London, Великобритания
Date of birth
Registered
Activity