Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что же в этом хорошего?
Ничего хорошего. Ты только не волнуйся.
ЭФ>База данных — самое немасштабируемое место в системе.
Не используй базы данных.
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы. Единая точка входа для чтения и записи в таблицу, полезно при рефакторинге и оптимизации структуры БД, аудита, разграничения прав и т.п. Лично я предпочитаю микросервис, но слой хранимых процедур тоже приемлемый вариант. Главное, стараться не добавлять туда бизнес-логику.
Здравствуйте, scf, Вы писали:
scf>По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы.
Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).
А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
K>Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).
K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
ерунда. как рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка, т.к. вермишель лишь в студенческих задачках гладко работает, а в реальных условиях не масштабируется и требует диких трудозатрат и костылей. в 80х и 90х наступали объектные субд, позволявшие хранить вермишель объекты в субд, потом были их подварианты с xml базами. когда объектные субд не взлетели начали натягивать ормы на реляционную модель. и это оказалось не работает, и ормы вышли из моды.
вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
Здравствуйте, Gt_, Вы писали:
Gt_>рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка
Я понял, что вы хотите сказать, и не возражаю. Да, классическая реляционная модель много раз доказала, что ничего лучше для сохранения данных пока не существует.
Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных
scf>Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных.
В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.
Здравствуйте, Kswapd, Вы писали:
K>В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.
Ну вот когда этот гипотетический компьютер перестанет быть гипотетическим, тогда и поговорим...
А пока будем говорить о реалиях.
Здравствуйте, Kswapd, Вы писали:
K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
Блин, где я это слышал??? Нет, ну говорил же кто-то... или не говорил... или делал??? Черт, вспомнил... Ну, у меня для тебя плохие новости — это DB2, оно уже сдохло.
Всё, что нас не убивает, ещё горько об этом пожалеет.
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Мартин в коме последние годы? in-memory storage в оракле уже лет пять реализован. причем "хранение" в памяти переделано на колончатое.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.
Здравствуйте, Kswapd, Вы писали:
K>"The Database Is a Detail" (Роберт Мартин).
Это настолько детская ошибка, что мне удивительно как то, что Мартин от нее до сих пор громко не отказался, как и то, что ее регулярно транслируют.
Я тут еще накидаю:
Presentation Layer Is a Detail.
Network Protocol Is a Detail.
Programming Language Is a Detail.
По факту же, попытка полностью абстрагироваться от деталей реализации хранилища заметно дороже, чем переписывание системы на другое хранилище при необходимости. Абстрагироваться стоит только там, где это не вредит качеству кода и не рушит производительность.
Здравствуйте, Gt_, Вы писали:
Gt_>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?
Gt_>>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.
SO_>Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?
я работаю со спарком и не вижу там такого тона. спарк используется восновном в обработке больших данных, соответственно позаимствовал у рсуб и подходы к обработке данных в рсубд хранилище — поменьше джоинов, побольше денормализации.
однако в стриминге и мелких инмемори датасетах спарка за джоин никто не наругает.
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе. E>Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.
все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.