Я это все к чему, я представляю структуру select'ов + join|unio для ваших отчетов (с учетом семплирование), она достаточно фиксированная.
Вот почему pg cluster привожу как пример, если не делать прям совсем кастом-кастом по любым датам и диапазонам то, интуитивно, такой rps получить можно, при всех прочих равных.
Короче, заинтересовали, буду щупать :)
Отчасти согласен, можно по дискутировать )
Но, замечу, по опыту, избыточность может привести к куда более страшные последствиям.
К примеру, консистентность данных при связи один к многим нельзя гарантировать. Тригеров я у вас не нашел, что означает, все на совести разработчика.
Кстати, говоря о консистентность, а какой уровень изоляции транзакции? И есть ли какие-то известные проблемы c network partition?
Еще такой вопрос, а нет ли у вас готового образа, ansible или чего-то такого чтобы я мог залить в AWS? Или только мне надо накатить ubuntu 14.* и поставить dep пакет?
Недавно была добавлена возможность внешней агрегации — с сохранением временных данных на диск. Эта возможность ещё не документирована.
Интересно! Жду доки, будет интересно огромную выборку попробовать.
Не тюнили. Более того, у нас тестировался довольно старый Hive, надо будет обновить.
Главное отличие — ClickHouse подходит для «онлайн» запросов из веб-интерфейса. То есть, скорость выполнения запросов позволяет выполнять запросы прямо в момент загрузки страницы с отчётом. Трудно представить себе сервис, в котором при каждом переходе между страницами, пользователь должен ждать выполнения запроса в Hive.
Вроде скоро из инкубатора выйдут новые проекты, ранее упоминали.
В hive'е добиться online можно, кешированием (горячие данные), hive (холодные), конечно доля online теряется, но и у вас не прям онлайн. Пока данные от счетчиков придут, пока зальется в кластер… это все латенси. Это я к чему, к тому что латенси в систему будет всегда.
(~2 млн. раз в сутки) — какое железо и сколько? Если не секрет :)
23 запросов в секунду, так то можно и посгрю натюнить даже для больших данных )
Я просто пытаюсь понять чем это лучше Hive, ES, кластер посгри. Так что не воспринимай как тролинг )
'Performance comparison of analytical DBMS' — а на каких конфигурациях (железо, оси) проводились тесты?
И правильно ли я понял: *MergeTree не поддерживает доп. индексы (точней только secondary Date)?
Я кстати не понял в чем радикальное отличие от Hive (если не считать скорости). Кстати как-то тюнили Hive или голый взяли?
Да и ваш map reduce ограничен оперативкой, верно я понял?
Прикольная тулзовина!
— (а зачем еще может понадобиться написание C/C++ addon кроме как для подключения сторонней библиотеки?)
Для оптимизации некоторых build-in функций — бывало такое ;)
Согласен.
— Эмитер с вызовом функции срабоет дважды или единожды?
1-н раз сработает, вроде, он не chain'ит callback'и (2-а раза повесить не пробовал — вывод логический).
Это статья не только про это, и что статья не новая было сказано. В ней есть много чего интересного, к примеру: как через pipe сделать chain of responsibility, явно не сказано но на мысли наводит; event drive…
А к деталям можно придраться в любом материале. ИМХО
Статья не новая, но мне показалась достаточно интересная.
Да промисы позволяют решить проблему. Но, точно знаю, что есть кучу кода который написан в old-style, не известно будут ли там внедрены промисы или нет, да и возможно ли такое внедрение не сломав API — вопрос. По этому domain все же имеет право на жизнь.
Все же, подумайте сделать образы, docker, ansible и т.п. — сегодня это user friendly)
Вот почему pg cluster привожу как пример, если не делать прям совсем кастом-кастом по любым датам и диапазонам то, интуитивно, такой rps получить можно, при всех прочих равных.
Короче, заинтересовали, буду щупать :)
Отчасти согласен, можно по дискутировать )
Но, замечу, по опыту, избыточность может привести к куда более страшные последствиям.
К примеру, консистентность данных при связи один к многим нельзя гарантировать. Тригеров я у вас не нашел, что означает, все на совести разработчика.
Кстати, говоря о консистентность, а какой уровень изоляции транзакции? И есть ли какие-то известные проблемы c network partition?
Интересно! Жду доки, будет интересно огромную выборку попробовать.
Вроде скоро из инкубатора выйдут новые проекты, ранее упоминали.
В hive'е добиться online можно, кешированием (горячие данные), hive (холодные), конечно доля online теряется, но и у вас не прям онлайн. Пока данные от счетчиков придут, пока зальется в кластер… это все латенси. Это я к чему, к тому что латенси в систему будет всегда.
23 запросов в секунду, так то можно и посгрю натюнить даже для больших данных )
Я просто пытаюсь понять чем это лучше Hive, ES, кластер посгри. Так что не воспринимай как тролинг )
И правильно ли я понял: *MergeTree не поддерживает доп. индексы (точней только secondary Date)?
Я кстати не понял в чем радикальное отличие от Hive (если не считать скорости). Кстати как-то тюнили Hive или голый взяли?
Да и ваш map reduce ограничен оперативкой, верно я понял?
— (а зачем еще может понадобиться написание C/C++ addon кроме как для подключения сторонней библиотеки?)
Для оптимизации некоторых build-in функций — бывало такое ;)
— Эмитер с вызовом функции срабоет дважды или единожды?
1-н раз сработает, вроде, он не chain'ит callback'и (2-а раза повесить не пробовал — вывод логический).
А к деталям можно придраться в любом материале. ИМХО
Да промисы позволяют решить проблему. Но, точно знаю, что есть кучу кода который написан в old-style, не известно будут ли там внедрены промисы или нет, да и возможно ли такое внедрение не сломав API — вопрос. По этому domain все же имеет право на жизнь.