Postgresql на 280 млн записей

Ребе theiced, вы можете там прокомментировать насчет производительности PostgreSQL?

Вообще я верю, что на 280 млн записей большинство баз начнет загибаться, если не принимать специальные меры, и ключевой вопрос, что эти меры должен принимать клиент на пару с dba (докидывать диски, партиционировать, ставить кластера и прочую херотень), желательно, без переписывания клиентского софта, потому что все то же самое можно сделать тупым образом, партиционируя данные ручками в клиентском приложении, и теряя преимущества от СУБД (запросы превращаются в тыкву, сторонние системы теряют возможность работать с данными, используя только внутреннюю информацию СУБД, и так далее)

Там предлагают решение типа отказатся от реляционных/sql баз и пилить все на заточенных под задачи NoSQL-поделках.

Неадекватные являния в ИТ, ака мозгоблудство

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

Это при том, что реально альтернативы нет, т.к. вариант "все то же самое сделать вручную" не масштабируем на мои задачи - нету 10 людей, которым можно было бы поставить задачу "садишся и в лоб делаешь таблицу из 20 полей, запросы для нее, валидаторы, GUI и печатную форму". А есть очень много повторяющихся кусков кода и общая структура, которая просто располагает к тому, чтобы это все сгенерить из модели.

Но ощущение неадекватности не пропадает.

По мотивам прогулок с собакой по весенней грязи

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

Очередная неизвестная мне аббревиатура

arbinada дал ссылку на обсуждение CQRS.
Смысл самой аббревиатуры я пока не осознал. Придумали новую шизу, опять в целях "не хотим реляционных БД".

Но сами идеи по ссылке, а так же то, что находится гуглом по ключевым словам, сильно перекликается с моими идеями насчет "log-based СУБД" с вкрученной функциональщиной.

Т.е. вместо объектов предметной области основным предметом моделирования становятся действия над ними, которые добавляются в базу (в моем представлении - только добавляются), транзакции становятся полноценными действиями, состоящими из множества других действий и позволяют явно управлять собой, версионность вместо средства физической реализации в СУБД становится тоже полноценно доступной функцией, все справочники становятся историческими и аудит действий мы получаем на халяву.
Запросы по такой СУБД нужно делать исключительно методом call-by-need с мемоизацией результатов в некоем кэше (вплоть до обычной РСУБД во фронт-енде). А сборка мусора, по идее, должна производится методом подчищения ненужной истории с заменой ее на снапшоты состояний.

Ну и еще хранение действий вместо данных у меня вызывает неадекватные ассоциации с point-free style и всякими стрелками и категориями.


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

Еще одна неоднозначная вещь.

А именно - интеграция со сторонними системами в плане данных.
Я, за 10 лет натрахавшись с разнообразными адаптерами, системами к которым нет никакого доступа кроме как реверс-инжинирить структуру файлов и прочитать, и прочим шлаком, в последнее время ударился в религию вида "схема базы должна быть понятна и доступна другим системам". Т.е. если, не дай б-г, через 15 лет кому-то понадобится интегрироваться с моей системой, а я буду в дурдоме - пусть лучше делают классическими средствами, подключаются к базе, итд. Хоть кристал репортсами, хоть из линукса запросы стандартным клиентом СУБД делают и баш скриптами с awk из них делают латеховые исходники и в pdf конвертируют.
Но вот люди считают иначе, причем, хотелось бы заменить, считают обоснованно. Некий разумный способ выставить интерфейс к бизнес-логике наружу (HTTP RESTful сервисы или там какой-нибудь более менее общеизвестный RPC) может оказаться более гуманным методом долбится в систему снаружи, чем лазить в ее БД.
Другое дело, что база данных обычно позволяет ad hoc извращения, а вот всякие веб-сервисы - только что что автор предусмотрел.