Исправление byko3y, (текущая версия) :
1. Ты упомнянул некоторое «дерево индексов». Можешь раскрыть тему?
Ну как бы индексы являются деревьями, тут секрета нет. Можно заметить, что каждая ветка индекса в отдельности тоже является индексом. Таким образом индекс ресурсивно является деревом из индексов. Для вставки уникального ключа в индекс можно лочить не весь индекс, а только ту ветку, в которой может быть этот индекс — это причина, по которой когда-то на иерархические БД возлагались большие надежды.
Те же Amazon S3 и Ceph очень активно используют шардирование по веткам, где перегруженное дерево бьется на две ветки, которые разъезжаются на разные сервера — такая архитектура, в отличие от случайного шардирования по хэшу, дает возможность собирать на одном сервере близкие сущности и выдавать список файлов в папке из одного сервера, а каждый раз опрашивать весь кластер. Это опять же к слову о причинной согласованности: в случае файлового хранилища близкими становятся сущности из одной папки. Другое дело, что далеко не всегда близкость по главному ключу является решающей — именно потому иерархические БД по большому счету сдохли, а возможность строить запросы по любым ключам были убийственной функцией реляционных табличек.
2. Ты сказал (не дословно), что «реляционная модель является источником проблем». Опять же, можешь раскрыть тему? Какие проблемы ты видишь и какая может быть альтернатива?
У нас есть клиент, клиент делает заказ — как клиенты относятся к заказам? 1-к-N? А может быть такое, что один клиент заказал, но для другого клиента? Сделал подарок, или заплатил. Первый постулат прикладного таблицестроения: в типовой прикладной задаче сущности всегда относятся друг к другу как хер-знает-что-к-черт-пойми-чему. Если ты попытаешься четко установить взаимосвязь, то в следующий же момент ты побежишь ее менять. А менять тип связи в реляционных таблицах очень больно — нужно переписывать все запросы после этого. Можно писать всё как N-к-M, но такой тип связи больно обрабатывать средствами SQL. По этой причине 99% интернет-магазинов плохо, очень плохо, еще хуже обрабатывают неожиданные ситуации при недоплате-переплате-отмене-замене-подмене-измене, «давайте отменим заказ и сделаем новый».
Далее, какие у нас столбцы-поля у заказа? Какой бы ты набор полей не выбрал, завтра прибежит менеджер с вопросом «куда мне записывать регион?». И тогда либо в «комментарии», то есть, key-value, который не подлежит обработке SQL и потому недопустим в рамках реляционной модели, либо создавать еще один столбец. Второй постулат прикладного таблицестроения: в типовой прикладной задаче число столбцов, ассоциированных с прикладной сущностью, стремится к бесконечности.
Именно по этим причинам все РСУБД неизбежно скатываются в key-value, которое позволяет хранить информацию неограниченной сложности и произвольными отношениями. Следующий шаг — это заменить бесполезный SQL на язык, который сможет делать запросы по key-value хранилищу — что активно делают в виде тех же JSON полей и расширений для запросов по ним. Другое дело, что это все еще костыли, а не фундаментальное решение проблемы.
Исходная версия byko3y, :
1. Ты упомнянул некоторое «дерево индексов». Можешь раскрыть тему?
Ну как бы индексы являются деревьями, тут секрета нет. Можно заметить, что каждая ветка индекса в отдельности тоже является индексом. Таким образом индекс ресурсивно является деревом из индексов. Для вставки уникального ключа в индекс можно лочить не весь индекс, а только ту ветку, в которой может быть этот индекс — это причина, по которой когда-то на иерархические БД возлагались большие надежды.
Те же Amazon S3 и Ceph очень активно используют шардирование по веткам, где перегруженное дерево бьется на две ветки, которые разъезжаются на разные сервера — такая архитектура, в отличие от случайного шардирования по хэшу, дает возможность собирать на одном сервере близкие сущности и выдавать список файлов в папке из одного сервера, а каждый раз опрашивать весь кластер. Это опять же к слову о причинной согласованности: в случае файлового хранилища близкими становятся сущности из одной папки. Другое дело, что далеко не всегда близкость по главному ключу является решающей — именно потому иерархические БД по большому счету сдохли, а возможность строить запросы по любым ключам были убийственной функцией реляционных табличек.
2. Ты сказал (не дословно), что «реляционная модель является источником проблем». Опять же, можешь раскрыть тему? Какие проблемы ты видишь и какая может быть альтернатива?
У нас есть клиент, клиент делает заказ — как клиенты относятся к заказам? 1-к-N? А может быть такое, что один клиент заказал, но для другого клиента? Сделал подарок, или заплатил. Первый постулат прикладного таблицестроения: в типовой прикладной задаче сущности всегда относятся друг к другу как хер-знает-что-к-черт-пойми-чему. Если ты попытаешься четко установить взаимосвязь, то в следующий же момент ты побежишь ее менять. А менять тип связи в реляционных таблицах очень больно — нужно переписывать все запросы после этого. Можно писать всё как N-к-M, но такой тип связи больно обрабатывать средствами SQL. По этой причине 99% интернет-магазинов плохо, очень плохо, еще хуже обрабатывают неожиданные ситуации при недоплате-переплате-отмене-замене-подмене-измене, «давайте отменим заказ и сделаем новый».
Далее, какие у нас столбцы-поля у заказа? Какой бы ты набор полей не выбрал, завтра прибежит менеджер с вопросом «куда мне записывать регион?». И тогда либо в «комментарии», то есть, key-value, который не подлежит обработке SQL и потому недопустим в рамках реляционной модели, либо создавать еще один столбец. Второй постулат прикладного таблицестроения: в типовой прикладной задаче число столбцов, ассоциированных с прикладной сущностью, стремится к бесконечности.
Именно по этим причинам все РСУБД неизбежно скатываются в key-value, которое позволяет хранить информацию неограниченной сложности и произвольными отношениями. Другое дело, что следующий шаг — это заменить бесполезный SQL на язык, который сможет делать запросы по key-value хранилищу — что активно делают в виде тех же JSON полей и расширений для запросов по ним. Другое дело, что это все еще костыли, а не фундаментальное решение проблемы.