Comments 46
Респект за труды! Подобный опыт с sql подобными выражениями и мы проходили на oracle coherence.
Но если трезво взглянуть на задачу, данные в ваших объемах можно было бы легко поместить в CitusDB или Greenplum например, где полноценный SQL и column oriented storage и кластеризуется при потребности. Да и Geenplum дружит с PostGIS расширением. Обе базы MPP, так что мороки с пухнущими индексами не должно быть.
Но если трезво взглянуть на задачу, данные в ваших объемах можно было бы легко поместить в CitusDB или Greenplum например, где полноценный SQL и column oriented storage и кластеризуется при потребности. Да и Geenplum дружит с PostGIS расширением. Обе базы MPP, так что мороки с пухнущими индексами не должно быть.
И прям с индексами на JSON/GEOJSON колонки?
В MPP системах индексы редко используют. Greenplum я не использовал, но CitusDB позволяет создавать GIST индексы по шардам.
Я так понимаю, вопрос именно в том, чтобы искать по geojson (во всяком случае, у меня в похожем проекте возникали именно такие задачи), а индекс по json это немножко не тоже самое, что обычный, это скорее похоже на полнотекстовый поиск.
Тогда Greenplum+PostGIS или CrateDB
Нам вообще хватило PostGIS в конечном итоге, так как результатов было еще чуть меньше, чем тут описывается.
Вопрос в том насколько ГринПлам сейчас актуален. Учитывая, что он на древнем движке Постгрес. У нас из-за при его тестировании под конкретную задачу были затык с переносом экстеншенов из более свежей ванильной версии постгрес. И, да, в наших задачах greenplum никакого серьезного прироста скорости не дал. Хотя брался за задачу пилота спец по Postgres/GreenPlum.
Ещё неясны перспективы greenplum в связи с усилением позиций clickhouse.
Мне лично Greenplum не понравился помимо всего вышеописанного, какой-то вымороченной инструкцией по установке, как будто из 90-х. Докеры? Оркестрация? Все мимо.
Ещё неясны перспективы greenplum в связи с усилением позиций clickhouse.
Мне лично Greenplum не понравился помимо всего вышеописанного, какой-то вымороченной инструкцией по установке, как будто из 90-х. Докеры? Оркестрация? Все мимо.
Намного актуальнее мегапопулярного Amazon Redshift, который основан на PostgreSQL 8.0.2. Действительно, произвольные расширения ванильного постгреса так легко не поставить на распределенные версии PostgreSQL. Но там и другой планировщик и другая схема хранения данных на диске.
CitusDB почти не накладывает ограничений на версию PostgreSQL и расширения. И предоставляется как сервис на AWS.
Clickhouse нишевый инструмент, который не может делать объединения между шардированными таблицами и поддержда SQL сильно ограничена. Clickhouse скорее конкурент Apache Druid, Apache Pinot.
Друг занимается администрированием Greenplum, могу узнать как он справляется. К тому же есть вариант хостить его в Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)
CitusDB почти не накладывает ограничений на версию PostgreSQL и расширения. И предоставляется как сервис на AWS.
Ещё неясны перспективы greenplum в связи с усилением позиций clickhouse.
Clickhouse нишевый инструмент, который не может делать объединения между шардированными таблицами и поддержда SQL сильно ограничена. Clickhouse скорее конкурент Apache Druid, Apache Pinot.
Мне лично Greenplum не понравился помимо всего вышеописанного, какой-то вымороченной инструкцией по установке, как будто из 90-х. Докеры? Оркестрация? Все мимо.
Друг занимается администрированием Greenplum, могу узнать как он справляется. К тому же есть вариант хостить его в Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)
Зачем пытаться использовать надстроенное РСУБД как NoSQL, если можно сразу использовать NoSQL? И на запись оно в разы быстрее получается, и вообще мороки меньше. Аэроспайк до 2 млрд. записей на инстанс — это поставил и забыл. Нам этого лимита надолго хватит.
Ответ обычно прост — записывать быстро, а вот извлекать и искать не удобно. Потому и появляются обычно свои парсеры и надстройки, когда извлекать нужно не по ключу и т.п. Потом оказывается что кода с NoSQL больше чем с SQL, часто разработка повторяет что что уже давно реализовано в объектно-реляционных MPP СУБД.
>Форматы хадуповского стека в этом смысле малопригодны
В смысле, чтобы GEOJSON что-ли хранить и по нему запросы произвольные писать?
В смысле, чтобы GEOJSON что-ли хранить и по нему запросы произвольные писать?
В том смысле, чтобы дописывать в сторидж результаты обсчёта новых порций, и забирать потом из веб-морды по запросу ко всем накопленным на момент запроса.
Ну, дописывать-то например можно в HBase, без особых проблем. Эту проблему он вам решит, особенно на таких объемах.
Можно, но мы живём в AWS. Там HBase держать вариантов немного. Либо в перманентном кластере EMR (дорого, неудобно), либо в S3 (медленно, опять неудобно, и есть ещё специфические болячки из-за асинхронности S3). Под NoSQL нужна одна виртуалка достаточных размеров, что сильно проще в администрировании.
UFO just landed and posted this here
Тут используется наверняка адищенские схемы шардирования.
Из коробки из ни в одной из «классических» БД типа Postgres и Mysql я не помню.
И как только Вы на это коммититесь, то приходится самому реализовывать транзакционность уже в распределенной среде, синхронизацию реплик etc.
Эту проблему решают NewSQL решения, но многие пока не дозрели до них.
Из коробки из ни в одной из «классических» БД типа Postgres и Mysql я не помню.
И как только Вы на это коммититесь, то приходится самому реализовывать транзакционность уже в распределенной среде, синхронизацию реплик etc.
Эту проблему решают NewSQL решения, но многие пока не дозрели до них.
UFO just landed and posted this here
Ну, так расскажите про свои ноу-хау, про нагрузку, про используемые технологические решения…
Это ж ведь правда очень интересно.
Реально сталкиваюсь с недостатком подобной информации, что и приводит к неверным ожиданиям от технологий, и, что хуже — к неверному их применению
Это ж ведь правда очень интересно.
Реально сталкиваюсь с недостатком подобной информации, что и приводит к неверным ожиданиям от технологий, и, что хуже — к неверному их применению
UFO just landed and posted this here
ну, опять. Я со всей душой, и опять набегают минусаторы…
К Вам, musicriffstudio. Вы вообще пока, знаете… создаете впечатление… некомпетентного человека. Вы же понимаете, что проблема не только и не сколько в кол-ве записей в базе. А в нагрузке — какие запросы (insert/update/delete) и в каком количестве прилетают. Условно — миллион просмотров страницы — это уже миллион селектов (минимум!). Я уж не говорю, про особенности типа VACUUM у Постгреса или то, что WAL всегда пишется в один поток (т.е. мы всегда блокируемся, когда у нас транзакционность и не забываем про уровни изоляции). Поэтому — да, миллион записей это немного. И, да, это ничего не значит в контексте нашей беседы.
И еще — коли уж миллион записей — типовая нагрузка, то чего тормозят всякие дешевые vpsочки с личными хостингами на друпале и вордпрессе?
Я, конечно, понимаю, что можно устроить хайлоад на ровном месте, но ведь инженерия заключается в том, чтобы это предотвратить.
И еще — хабр это же ведь не только странички и пользователя. Это как минимум несколько разных проектов, с общими кусками (типа базы юзеров), с разной нагрузкой (причем еще вопрос какой, но точно не 10rps). И как эта кухня устроена внутри — снаружи абсолютно неясно.
К Вам, musicriffstudio. Вы вообще пока, знаете… создаете впечатление… некомпетентного человека. Вы же понимаете, что проблема не только и не сколько в кол-ве записей в базе. А в нагрузке — какие запросы (insert/update/delete) и в каком количестве прилетают. Условно — миллион просмотров страницы — это уже миллион селектов (минимум!). Я уж не говорю, про особенности типа VACUUM у Постгреса или то, что WAL всегда пишется в один поток (т.е. мы всегда блокируемся, когда у нас транзакционность и не забываем про уровни изоляции). Поэтому — да, миллион записей это немного. И, да, это ничего не значит в контексте нашей беседы.
И еще — коли уж миллион записей — типовая нагрузка, то чего тормозят всякие дешевые vpsочки с личными хостингами на друпале и вордпрессе?
Я, конечно, понимаю, что можно устроить хайлоад на ровном месте, но ведь инженерия заключается в том, чтобы это предотвратить.
И еще — хабр это же ведь не только странички и пользователя. Это как минимум несколько разных проектов, с общими кусками (типа базы юзеров), с разной нагрузкой (причем еще вопрос какой, но точно не 10rps). И как эта кухня устроена внутри — снаружи абсолютно неясно.
В данном случае впечатление некомпетентного человека создаете именно вы. Да, разумеется, проблема в операциях, а не в количестве записей! Так почему же вы продолжаете доказывать, что миллионы записей представляют хоть какую-то проблему?
И еще — коли уж миллион записей — типовая нагрузка, то чего тормозят всякие дешевые vpsочки с личными хостингами на друпале и вордпрессе?
Предположу, что там мегарасширяемый код с кучей плагинов. Подобные архитектуры плохо дружат с любыми СУБД.
Зря вы начали ломать «прекрасный новый мир» в голове любителя современных решений…
Мускул на старых машинах и простых фреймворках быстро крутит 40миллионов строк. Другие технологии нужны, когда у вас терабайтные базы (да и то, Microsoft SQL Server осиливает 30 ТБ)
UFO just landed and posted this here
Вообще-то это не показатель. Этот сайт наполняется людьми, и этих людей, так же как их комментариев, вполне небольшое число, и небольшая производительность по генерации данных. Например, у меня всего 1.5 тысячи комментариев с 2012 года, а уж постов и подавно. Что наводит как-бы на мысль, что производительность операций типа INSERT тут вообще никакой роли может не играть.
Ну и потом, в постановке задачи JSON (и его индексация). И именно в нее, как я понимаю, все и упиралось.
И да, когда говорят «миллионы записей» — иногда имеют в виду «в день» :) Хорошо бы это уточнить, а то это две большие разницы.
Ну и потом, в постановке задачи JSON (и его индексация). И именно в нее, как я понимаю, все и упиралось.
И да, когда говорят «миллионы записей» — иногда имеют в виду «в день» :) Хорошо бы это уточнить, а то это две большие разницы.
Вот же мучаются люди без Vertica! Бесплатно до 1тб данных и 3 узлов в кластере. Ваша задача отлично решается с помощью flex tables.
И все-таки, чем вам не угодил рекурсивный expr? Получить постфиксную форму из уже построенного AST можно тривиально.
Можно, не спорю. Но чем плохо попрактиковаться с альтернативными подходом?
А задача была «попрактиковаться» или разобрать запрос? Если первое, то я не понимаю зачем вообще использовать ANTLR. Если второе — то имеет смысл поручить всю работу ANTLR.
Не понимаю сути вашей претензии, если честно. Что именно не так, по-вашему, я сделал с ANTLR?
Если хотите быть конструктивным, киньте ссылку на пример кода, который считаете правильным, вместо того, чтобы ворчать.
Если хотите быть конструктивным, киньте ссылку на пример кода, который считаете правильным, вместо того, чтобы ворчать.
Кинуть ссылку я не могу — у меня под рукой нет antlr. Но, судя по документации, он умеет справляться с тем рекурсивным форматом которого вы почему-то испугались.
Например, если дать ему вот такое выражение: a * b + c * d, то будет построено вот такое дерево:
+
/ \
/ \
* *
/ \ / \
a b c dТеперь это дерево нужно всего лишь правильно рекурсивно обойти, чтобы получить постфиксную запись.
Ну вот вот код на C#:
class Program : SQLiteBaseVisitor<bool>
{
public override bool VisitParameter(SQLiteParser.ParameterContext context)
{
Push(context.id.Text);
return false;
}
public override bool VisitBinary(SQLiteParser.BinaryContext context)
{
foreach (var expr in context.expr())
Visit(expr);
Push(context.op.Text);
return false;
}
// ...
}Входная строка: a*b - (c+d)/e
Выходная последовательность: a b * c d + e / -
Замечу, что мне даже не пришлось добавлять отдельное правило для скобок — antlr справился за меня. Ну, в реальном коде будут еще обработчики для унарных операций, для литералов и для LIKE/NOT LIKE.
Все равно же получается намного проще чем вы сделали!
Возможно я вас огорчу, но такое решение не подходит под все условия задачи.
Вы парсите абстрактное дерево как абстрактное дерево, а мой случай — он вообще-то конкретный. То предикатное API, которое я обёртываю в SELECT — типизированное, и набор допустимых операций для каждого типа свой. Если бы я использовал ваш вариант (впрочем, во времена ANTLR v3 я бы тоже такой заюзал, потому что другого и не было), мне пришлось бы добавлять дополнительную логику для каждого типа предиката где-то после разбора.
А тут я её пишу прямо по месту, в контексте конкретного чё_нибудь_expr.
Общая сложность в итоге вышла бы ровно такая же, так что спорить тут на самом деле не о чем :)
Вы парсите абстрактное дерево как абстрактное дерево, а мой случай — он вообще-то конкретный. То предикатное API, которое я обёртываю в SELECT — типизированное, и набор допустимых операций для каждого типа свой. Если бы я использовал ваш вариант (впрочем, во времена ANTLR v3 я бы тоже такой заюзал, потому что другого и не было), мне пришлось бы добавлять дополнительную логику для каждого типа предиката где-то после разбора.
А тут я её пишу прямо по месту, в контексте конкретного чё_нибудь_expr.
Общая сложность в итоге вышла бы ровно такая же, так что спорить тут на самом деле не о чем :)
Я не увидел в вашем методе exitWhere_expr никакой особой обработки типизированных предикатов, это в чистом виде реализация алгоритма сортировочной станции. Всё что вы там делаете — это переупорядочиваете ноды и складываете их в контейнер predExpStack.
В моём варианте на выходе получается точно такой же predExpStack, только пишется мой вариант гораздо проще вашего.
В моём варианте на выходе получается точно такой же predExpStack, только пишется мой вариант гораздо проще вашего.
Если у вас всё же не совсем абстрактный JSON, а данные, пусть и с большим, но фиксированным количеством колонок — то попробуйте clickhouse.yandex.
Да вроде было написано, что фиксированной схемы как раз нет. Мы в общем примерно на такое натыкались, когда пытались отразить в свою схему структуру OSM, где число тэгов заранее неизвестно, и вообще говоря — нигде не описано (читай — иногда растет). Так что сделать скажем по колонке на тэг — не решение вообще.
Sign up to leave a comment.
Нельзя так просто взять и написать SELECT, если вендор не разрешает… но мы таки напишем