Comments 46
Но если трезво взглянуть на задачу, данные в ваших объемах можно было бы легко поместить в CitusDB или Greenplum например, где полноценный SQL и column oriented storage и кластеризуется при потребности. Да и Geenplum дружит с PostGIS расширением. Обе базы MPP, так что мороки с пухнущими индексами не должно быть.
Ещё неясны перспективы greenplum в связи с усилением позиций clickhouse.
Мне лично Greenplum не понравился помимо всего вышеописанного, какой-то вымороченной инструкцией по установке, как будто из 90-х. Докеры? Оркестрация? Все мимо.
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)
В смысле, чтобы GEOJSON что-ли хранить и по нему запросы произвольные писать?
Из коробки из ни в одной из «классических» БД типа Postgres и Mysql я не помню.
И как только Вы на это коммититесь, то приходится самому реализовывать транзакционность уже в распределенной среде, синхронизацию реплик etc.
Эту проблему решают NewSQL решения, но многие пока не дозрели до них.
Это ж ведь правда очень интересно.
Реально сталкиваюсь с недостатком подобной информации, что и приводит к неверным ожиданиям от технологий, и, что хуже — к неверному их применению
К Вам, musicriffstudio. Вы вообще пока, знаете… создаете впечатление… некомпетентного человека. Вы же понимаете, что проблема не только и не сколько в кол-ве записей в базе. А в нагрузке — какие запросы (insert/update/delete) и в каком количестве прилетают. Условно — миллион просмотров страницы — это уже миллион селектов (минимум!). Я уж не говорю, про особенности типа VACUUM у Постгреса или то, что WAL всегда пишется в один поток (т.е. мы всегда блокируемся, когда у нас транзакционность и не забываем про уровни изоляции). Поэтому — да, миллион записей это немного. И, да, это ничего не значит в контексте нашей беседы.
И еще — коли уж миллион записей — типовая нагрузка, то чего тормозят всякие дешевые vpsочки с личными хостингами на друпале и вордпрессе?
Я, конечно, понимаю, что можно устроить хайлоад на ровном месте, но ведь инженерия заключается в том, чтобы это предотвратить.
И еще — хабр это же ведь не только странички и пользователя. Это как минимум несколько разных проектов, с общими кусками (типа базы юзеров), с разной нагрузкой (причем еще вопрос какой, но точно не 10rps). И как эта кухня устроена внутри — снаружи абсолютно неясно.
В данном случае впечатление некомпетентного человека создаете именно вы. Да, разумеется, проблема в операциях, а не в количестве записей! Так почему же вы продолжаете доказывать, что миллионы записей представляют хоть какую-то проблему?
И еще — коли уж миллион записей — типовая нагрузка, то чего тормозят всякие дешевые vpsочки с личными хостингами на друпале и вордпрессе?
Предположу, что там мегарасширяемый код с кучей плагинов. Подобные архитектуры плохо дружат с любыми СУБД.
Ну и потом, в постановке задачи JSON (и его индексация). И именно в нее, как я понимаю, все и упиралось.
И да, когда говорят «миллионы записей» — иногда имеют в виду «в день» :) Хорошо бы это уточнить, а то это две большие разницы.
Вот же мучаются люди без Vertica! Бесплатно до 1тб данных и 3 узлов в кластере. Ваша задача отлично решается с помощью flex tables.
И все-таки, чем вам не угодил рекурсивный expr? Получить постфиксную форму из уже построенного AST можно тривиально.
Если хотите быть конструктивным, киньте ссылку на пример кода, который считаете правильным, вместо того, чтобы ворчать.
Кинуть ссылку я не могу — у меня под рукой нет 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.
Общая сложность в итоге вышла бы ровно такая же, так что спорить тут на самом деле не о чем :)
В моём варианте на выходе получается точно такой же predExpStack, только пишется мой вариант гораздо проще вашего.
Нельзя так просто взять и написать SELECT, если вендор не разрешает… но мы таки напишем