Чувствую, что несу чушь,

[metaclass]

но не могу отделаться от ощущения, что с эволюцией баз данных нас очень сильно наебали.
Это по поводу этого: http://plumqqz.livejournal.com/323506.html
Меня очень сильно бесит расхождение технологий: с одной стороны, классические СУБД, с другой NoSQL, с третьей - всякие in-memory распределенные базы, с четвертой - всякие аналитические БД с column storage, сжатием данных и перекосом в сторону чтения типа vertica, sybase iq или забиваторской QD. Плюс еще всякие datomic до которой я никак добраться не могу.

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

Comments

[metaclass.livejournal.com]

UPDATE Counters
SET @value = value = value + 1
WHERE counter = @counter
Закапываем. Работает только в MSSQL.

[lazy-flyer.livejournal.com]

Я о приземлённом. О продажах, финансах...

[metaclass.livejournal.com]

Шапка: 1 запись
Строки: 1-N записей, до 100 условно
Какая-нибудь блокировка товара на складе - еще столько же записей.
История действий пользователей - в зависимости от реализации - от одной до N*количество действий записей
Если этот документ связан с другими - еще записи в таблицах связей.

Если же это реализовать более менее универсальным образом, то в случае EAV - сразу под тысячу записей, но всего в двух-трех таблицах (обкрученных индексами по всем полям, что эффективно увеличивает размер в 2-3 раза).

[maxdz.livejournal.com]

А чем последовательные Id не подходят?

Как сказано оратором выше, одним запросом берётся максимальный Id таблицы (для этого есть специальная аггрегатная функция, которая в ANSI стандарте), а потом в программе генерируется следующий уникальный Id = полученный максимальный Id + 1 и с таким Id делается вожделенный инсерт.

Очень сложно? :)

[plumqqz.livejournal.com]

Скажите, а вы хорами имена объектов не шифруете?

[metaclass.livejournal.com]

Это не работает. Нужно блокировать таблицу целиком на все время выборки и вставки, за что в приличных домах пиздят канделябрами. Ну или поиметь конфликт значений PK.

[lazy-flyer.livejournal.com]

Ндя...
В 2004-м году мне удалось достичь размера базы за год в ~600 МБ. При шестизначном номере инвойса...
База - в целом всей системы, вся логистика и финансы. Я бесконечно отстал от жизни.

[maxdz.livejournal.com]

Нет никакой выборки. select max(Id) - это запрос, который в индексированной по Id таблице выполняется за миг.

П.С. Ок, атомарности генерации Id и инсерта в таком случае на уровне СУБД не обеспечивается - но атомарность обеспечат инсерты, только через отдельную функцию бизнес-логики и никак иначе.

[metaclass.livejournal.com]

Ребе, сейчас сюда придут рабы стагнирующего колхоза и северо-мордорские орки и будут вас травить :)

смотрите картину:
клиент 1: select max(id) from table
клиент 2: select max(id) from table
клиент 1: insert into table(id) values(...)
клиент 2: insert into table(id) values(...) -> PK violation

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

далее, select max(id) не работает мгновенно в MVCC архитектуре - ему нужно выяснить, "какую из версий таблицы я вижу". Надо бы проверить это дело в MSSQL и Postgresql, возможно, там что-то заоптимизировано на эту тему.


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

[maxdz.livejournal.com]

Я написал в P.S. - инсерты должны выполняться только через отдельную функцию, а не напрямую. Это может быть хранимая процедура (но такое не есть хорошо), а может быть функция бизнес-логики.

Когда несколько клиентов имеют возможность делать апдейты/инсерты в БД, напрямую (минуя бизнес-логику, с единообразной организацией/валидацией апдейта/инсерта) - это, в любом случае, нехорошо.

[berezovsky.livejournal.com]

в пределе это может тормозить, и надо пользоваться средствами конкретной БД

[maxdz.livejournal.com]

Чтобы не тормозило - есть т.н. "аппликэйшн сервера". Но при этом, вынесение всей непосредственной работы с БД на уровень бизнес-логики из клиентов, даёт массу преимуществ, которые с SQL запросами в коде клиентов никак не реализуются.

Да и разница в быстродействии не так уж велика, если вообще (и нивелируется недостатками такой "2-уровневой" архитектуры).

П.С. Единственный легитимный вариант, когда SQL запросы имеют право быть в коде клиента - если клиент работает с выделенной/персональной базой данных, в экслюзивном режиме.

[zamotivator.livejournal.com]

> Но специализированные решения для хранения разряженных многомерных массивов более производительны.

О, а можно поподробней о таких решениях?
Я как раз такое пилю right now - SciDB

[zamotivator.livejournal.com]

Microsoft?

[zamotivator.livejournal.com]

Скажите, а зачем вам менять базы как перчатки?

[berezovsky.livejournal.com]

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

[maxdz.livejournal.com]

Гы-гы. Идеальных/универсальных решений не бывает. Кому-то хочется от БД одного, кому-то иного. Да и конкуренция вынуждает производителей быть в тонусе и делать всё лучшие решения, вместо говна.

Так что, незачем требовать таких глупостей, как единая БД от всех и для всех. :)

[berezovsky.livejournal.com]

Если я правильно представляю, в случае, когда вставка не сработает, ключи должны возвращаться на родину.
Для этого одна транзакция должна быть вложена в другую, что должно быть отражено в стандарте.
Или я перемудрил?

[nicka-startcev.livejournal.com]

чтоб при обнаружении какого-нибудь критического дерьма в сочетании, например, оракал-1.2.3.х86+ие7.40 + вин6.22 тупо быстро и безболезненно сменить оракал-1.2.3.х86 на какой-нибудь MySKL-666.740-амд64.

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

или чтоб после смерти оракала не нанимать стопицот работников на перепроектирование всего с нуля и года дозатыкания дыр.

В общем, для безболезненной миграции при изменении условий.

[berezovsky.livejournal.com]

философия новой эры же :-(

[plumqqz.livejournal.com]

Конечно перемудрили. Зачем их возвращать? Хвала Всевышнему - когда он создавал числа, он создал их достаточно.

[plumqqz.livejournal.com]

Работаете? Ну-ну.

[zamotivator.livejournal.com]

Сколько мифов в одном комментарии

[kranov.livejournal.com]

так смысла нет про вертику говорить, 48гиг озу стоит $500, а вот если 10-ки терабайт, и результат через нужен минуту

[theiced.livejournal.com]

так в маськовских лавках тоже же хуйню платят. если выкинуть разницу на аренду жилья - один херъ получается.