Здравствуйте, IncremenTop, Вы писали:
IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен?
ACID это здравый смысл, он нужен всегда.
Не всегда он нужен в базе данных, так как механизмы обепечения acid тяжеловесные, для ускорения иногда можно взть не-acid базу и сделат acid силами приложения.
Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
IT>За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени.
А чего неудобного в хранении таких данных в БД?
IT>Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная. А учитывая навороченные инструменты работы с РСУБД в совремеенных язках, еще и довольно удобная для программиста.
Здравствуйте, IncremenTop, Вы писали:
IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.
Альтернативы какие предлагаешь? Key value store? Да, на первом этапе это выглядит как нормальное решение. Однако потом бизнеслогика даже небольшого проекта разрастается. Начинаются потребности в миграциях данных и рефакторинге схемы данных. Появляется необходимость в поиске по другим критериям, отличным от дай мне объект по идентификатору. И в результате начинаем на ровном месте писать считай свою реляционную надстройку над key value store, и там, где целостность данных у нас проверяет реляционка посредством внешних ключей, уникальных ключей, тут ты этот функционал хреначишь ручками сам. И это я не говорю о таких приколах, как возможные повреждения самого персистентного файла. Плавал, знаю. Одно время тоже повелся на то, что щас без реляционки обойдусь, мне нужна только простейшая персистентность. И блин прямо перед релизом потребовался функционал, который в реляционки из коробки. В срочном порядке практически за сутки поменял хранилище на реляционку и реализовал недостающую логику на ней, вот только кое что поменять не успел, в результате чего кое что осталось по старому и потом огребал проблемы с целостностью данных. С тех пор реляционки я ОЧЕНЬ люблю и считаю это решением по умолчанию практически для всего. Хотя вот конкретно сейчас у меня снова все хранится непосредственно в файловой системе как memory mapped files, а из реляционки я только изначально все вычитываю, реляционка у меня только на чтение, но тут уже идет специфика проекта. Круто без реляционки только в самом начале проекта. А далее требования и хотелки меняются, и уже очень сильно либо жалеешь что не стал делать на реляционке сразу.
И дополнительно, относительно микросервисов. Сейчас индустрия пришла к пониманию, что это далеко не серебряная пуля, у них есть свои границы применимости и не надо их лепить вообще везде, во многих случаях монолиты рулят просто неимоверно. У нас не везде страшнейший хайлоад с требованием горизонтального масштабирования. А деление системы на даже не микро, а просто сервисы — чаще всего оборачивается весьма нехилым геморроем по обеспечению согласованности данных между сервисами, получается отдельная логика по конвертации разных форматов данных на ровном месте, и не всегда это оказывается реально оправдано.
Re[2]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, gandjustas, Вы писали:
G>ACID это здравый смысл, он нужен всегда.
Нет, в многих нагруженных систем от него ушли в сторону саги. Потому что почти всегда нужна асинхронность на уровне процессов.
G>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.
G>А чего неудобного в хранении таких данных в БД?
Опустим то, что это надо проектировать, а не из коробки использовать.
Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.
G>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.
Прошло почти полсотни лет.
Re[2]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, elmal, Вы писали:
E>И дополнительно, относительно микросервисов. Сейчас индустрия пришла к пониманию, что это далеко не серебряная пуля, у них есть свои границы применимости и не надо их лепить вообще везде, во многих случаях монолиты рулят просто неимоверно. У нас не везде страшнейший хайлоад с требованием горизонтального масштабирования. А деление системы на даже не микро, а просто сервисы — чаще всего оборачивается весьма нехилым геморроем по обеспечению согласованности данных между сервисами, получается отдельная логика по конвертации разных форматов данных на ровном месте, и не всегда это оказывается реально оправдано.
Спасибо за капитанство, но это не повод лепить микросервисы и одну рбд в один проект.
Re[3]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
G>>ACID это здравый смысл, он нужен всегда.
IT>Нет, в многих нагруженных систем от него ушли в сторону саги. Потому что почти всегда нужна асинхронность на уровне процессов.
G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься.
IT>Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.
Количество табличек для ACID совершенно параллельно, ACID бывает полезен и на одной таблице, если к ней идёт несколько логически связанных запросов, что иногда бывает, т.к. напихать всё в один SQL не всегда получается. Особенно если такое логически связанные запросы к этой таблице могут идти из параллельных потоков или клиентов, т.к. каждый поток создает логическую группу запросов. В этом случае спасает только транзакция, иначе будет race condition.
Я например сейчас пишу шареварную программу с SQLite в качестве локального хранилища, там всего одна табличка, но без ACID в ней появились бы гейнзенбаги, и наверняка уже на стадии прода.
Здравствуйте, IncremenTop, Вы писали:
IT>Спасибо за капитанство, но это не повод лепить микросервисы и одну рбд в один проект.
А где написано что там одна РБД? На деле, ничего не мешает иметь действительно одну реляционку с охрененной нормализацией, с охрененной целостностью. И до черта вспомогательных баз, которые заточены под другие операции, какие то под отчетность, какие то под быструю вставку грязных данных, которые потом отдельными службами вычищаются и очищенные чистые данные переходят в основную хорошо нормализуемую и с хорошей целостностью. Основная база вполне может быть мало нагружена даже в единственном экземпляре, она может использоваться в основном под вставку чистых данных. А запросы могут идти к многочисленным репликам в основном, причем многие будут иной структуры. Причем еще вполне может применяться различное кеширование, соответственно нагрузка на базу вполне может быть достаточно небольшая. Потребность в чистых данных с хорошей целостностью возникает очень и очень часто, и реляционки для обеспечения целостности данных на уровне базы рулят просто неимоверно. А способов избавиться от возможных проблем с производительностью до черта и более.
Re[3]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Нет, в многих нагруженных систем от него ушли в сторону саги.
Вынужденно ушли.
IT>Потому что почти всегда нужна асинхронность на уровне процессов.
Э-э-э... Я понял в чём твоя проблема. Ты решение принимаешь за цель.
Нужна не асинхронность на уровне процессов, а время отклика.
G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься. IT>Аcid — это такое же перепроектирование
Какое "такое же перепроектирование", если речь идёт о преждевременной оптимизации?
IT>Опустим то, что это надо проектировать, а не из коробки использовать.
А что есть решение, которое можно в любом проекте из коробки использовать, а не проектировать что-то с использованием этого решения?
IT>Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
Подробнее можно?
IT>При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее.
За счёт чего? Быстрее чего? На каких сценариях быстрее?
IT>Прошло почти полсотни лет.
А дважды два, по-прежнему, четыре. Доколе?!
Re[4]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, gyraboo, Вы писали:
G>Я например сейчас пишу шареварную программу с SQLite в качестве локального хранилища, там всего одна табличка, но без ACID в ней появились бы гейнзенбаги, и наверняка уже на стадии прода.
Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.
Re[5]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
G>>Я например сейчас пишу шареварную программу с SQLite в качестве локального хранилища, там всего одна табличка, но без ACID в ней появились бы гейнзенбаги, и наверняка уже на стадии прода.
IT>Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.
А ссылочную целостность они дают, если я передумаю и захочу через какое-то время разработки добавить и вторую таблицу? (у меня так и произошло на самом деле сейчас)
Re[3]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>ACID это здравый смысл, он нужен всегда. IT>Нет, в многих нагруженных систем от него ушли в сторону саги.
Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу.
Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".
IT>Потому что почти всегда нужна асинхронность на уровне процессов.
Асинхронность и ACID не связаны.
G>>Но это часть оптимизации, предварительной оптимизацией лучше не заниматься. IT>Аcid — это такое же перепроектирование, когда есть две таблички, а люди лепят РБД.
Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?
G>>А чего неудобного в хранении таких данных в БД? IT>Опустим то, что это надо проектировать, а не из коробки использовать. IT>Но уж то, что нет инструментов из коробки, которые умеют в анализ и, например, свертку.
Тут нужна конкретика.
Вот есть данные с вот такой схемой, и вот такие запросы.
Нереляционная БД Х делает вот такие запросы, а РСУБД — не может так делать, потому что У.
А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую релеляционную БД.
IT>При этом по скорости, если уж лепить из непрофильного, например, из касандры ТСДБ, то она будет на порядки быстрее. G>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная. IT>Прошло почти полсотни лет.
Теореме пифагора уже тысячи лет, это не делает её менее верной.
В мире математики рулит доказательство, а не частное мнение. Неуниверсальность РСУБД надо доказать. Для этого надо описать класс данных (схемы) и операции над ними, которые запросами в РСУБД сделать невозможно или крайне сложно и неэффективно.
Re[5]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, gyraboo, Вы писали:
G>>Я например сейчас пишу шареварную программу с SQLite в качестве локального хранилища, там всего одна табличка, но без ACID в ней появились бы гейнзенбаги, и наверняка уже на стадии прода.
IT>Транзакционность на уровне одной "таблицы" поддерживают многие неРБД.
Ты путаешь. Транзакционность (то есть атомарность, зачастую даже без долговечности) на уровне одной ЗАПИСИ поддерживают все базы, в рамках одного инстанса конечно же. Иначе было бы сильно сложнее сделать.
Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.
Re[4]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, gandjustas, Вы писали:
G>Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу. G>Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".
Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага.
Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.
G>Асинхронность и ACID не связаны.
Связана.
Если у вас в рамках транзакции 2 и более сервисов, то это распределенная транзакция, которые суть зло по сравнению даже со сложностью саги. И если взаимодействией асинхронное между сервисами, то либо вы еще транзакционность добавляете в шину(а это очень медленно), либо это уже транзакция-сага. Непонятный франкенштейн.
В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.
G>Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД?
Я говорю о табличках, потому что мы не определились, какую NoSQL бд описываем. Терминология даже у еластика плавает от версии к версии.
Я ничего не сказал о взаимосвязях.
G>А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую релеляционную БД.
Так я перечислил эти фичи.
G>>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная.
Они это не доказывали, цель была в том чтобы построить максимально полную, непротиворечивую и неизбыточную модель.
Выше я давал примеры, когда монга по скорости была гораздо эффективнее постгре. В принципе логично, что специализированный инструмент всегда будет эффективнее в рамках специализации универсального всемогутора.
Re[5]: Зачем реляционные БД...в небольших проектах?
IT>Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага. IT>Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.
ты втирал "в небольших проектах", применять сагу на небольшом проекте признак проф непригодности. особенно в контексте разговора о производительности.
IT>В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.
или шлете дилетанта, что в небольшой проекте, где все решается микротранзакцией устраивает саги.
IT>Выше я давал примеры, когда монга по скорости была гораздо эффективнее постгре. В принципе логично, что специализированный инструмент всегда будет эффективнее в рамках специализации универсального всемогутора.
не давал. клоуны с бложиком и комментами не в счет, там бизнес логики нет.
Здравствуйте, Gt_, Вы писали:
Gt_>ты втирал "в небольших проектах", применять сагу на небольшом проекте признак проф непригодности. особенно в контексте разговора о производительности.
Мы сейчас в целом о проектах разговариваем, если ты не заметил.
Gt_>не давал. клоуны с бложиком и комментами не в счет, там бизнес логики нет.
Советую следить за речью все же, вас никто не оскорблял.
Re[4]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, elmal, Вы писали:
E>А запросы могут идти к многочисленным репликам в основном, причем многие будут иной структуры. Причем еще вполне может применяться различное кеширование, соответственно нагрузка на базу вполне может быть достаточно небольшая. Потребность в чистых данных с хорошей целостностью возникает очень и очень часто, и реляционки для обеспечения целостности данных на уровне базы рулят просто неимоверно. А способов избавиться от возможных проблем с производительностью до черта и более.
И зачем?
Целостность данных нарушается, как только у вас возникает хоть что-то помимо монолита в одной операции. И тут внезапно оказывается, что протаскивать одну транзакцию везде дорого, неэффективно и долго.
И если у тебя уже несколько РБД, то потом еще согласовывай данные между ними, внезапно.
Способов избавиться от проблем с производительностью меньше, потому что не масштабируется горизонтально.
Re[6]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, gandjustas, Вы писали:
G>Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.
Не путаю как раз. Транзакционность на уровне одной таблицы монгодб(собственно мультидокументную тоже уже поддерживается между разными репликами) поддерживает достаточно давно, не говоря о других БД.
Re[5]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Это проблема систем. С точки зрения пользователя и бизнеса большинство транзакций — ACID, дал денег — получил товар, — получил деньги — оказал услугу. G>>Часто вы покупали что-то в магазине, а вам вместо товара говорили "данные получены, когда-нибудь вы получите товар, наверное".
IT>Нет. Когда я покупаю товар, то я делаю несколько действий. Т.е. это сага. IT>Мало того, товар может зарезервироваться на складе, но оплата не прошла и логично не откатить все, а предложить пользователю попробовать еще раз. И это тоже возможно в рамках саги.
И все это обладает признаками ACID. Оплата не прошла — товар не поставлен, прошла — поставлен.
Еще раз: асинхронность и ACID не связаны.
Если у тебя в рамках "саги" (очередной модный термин) какой-то из шагов не поддерживает транзакции и ACID, то придется самостоятельно приседать чтобы обеспечить транзакционность всего процесса.
G>>Асинхронность и ACID не связаны. IT>Связана.
Нет
IT>Если у вас в рамках транзакции 2 и более сервисов, то это распределенная транзакция, которые суть зло по сравнению даже со сложностью саги. И если взаимодействией асинхронное между сервисами, то либо вы еще транзакционность добавляете в шину(а это очень медленно), либо это уже транзакция-сага. Непонятный франкенштейн.
Ты очень сильно привязываешься в техническим деталям вместо понимания сути транзакций.
IT>В итоге либо вы шлете к чертям ДДД вместе с кроликами и кафкой, либо вы шлете к чертям 2pc.
Послать подальше ДДД это хорошо, остальное я даже не понял о чем речь.
G>>Когда ты говоришь о "табличках" ты уже пользуешься реляционной моделью данных. Почему бы для нее не использовать РСУБД? IT>Я говорю о табличках, потому что мы не определились, какую NoSQL бд описываем. Терминология даже у еластика плавает от версии к версии.
"Таблички" == реляционная модель == удобно использовать ЛЮБУЮ РСУБД. Все РСУБД построены на основе одно и того же набора операций.
IT>Я ничего не сказал о взаимосвязях.
И не надо. Это ни на что не влияет.
G>>А просто сравнивать фичи бесполезно. РСУБД по общему набору фич и покрываемых сценариев порвет любую нерелеляционную БД. IT>Так я перечислил эти фичи.
Сосредоточься. Я говорю что сравнивать по фичам БЕСПОЛЕЗНО. Нужны схемы данных и запросы.
G>>>>"Виноваты" ученые, которые доказали что реляционная модель данных позволяет решать те же задачи, что и любые другие модели. Поэтом реляционная субд — универсальная. IT>Они это не доказывали, цель была в том чтобы построить максимально полную, непротиворечивую и неизбыточную модель.
Они это доказывали.
IT>Выше я давал примеры, когда монга по скорости была гораздо эффективнее постгре.
Логично что кэш быстрее не самой шустрой РСУБД.
IT>В принципе логично, что специализированный инструмент всегда будет эффективнее в рамках специализации универсального всемогутора.
Ты сейчас занимаешься предварительной оптимизацией.
Re[7]: Зачем реляционные БД...в небольших проектах?
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Транзакционность (ACID) на уровне одной таблицы поддерживют РСУБД и технически она реализуется также, как и транзакционность на уровне нескольких таблиц.
IT>Не путаю как раз. Транзакционность на уровне одной таблицы монгодб(собственно мультидокументную тоже уже поддерживается между разными репликами) поддерживает достаточно давно, не говоря о других БД.
Монга не поддерживает ACID на уровне таблицы.
Если ты уверен в обратном, то покажи как реализовать:
— Есть таблица счетов (балансов)
— Нужно реализовать операции перевода между счетам — уменьшить баланс на одном и увеличить на другом
— Баланс не должен опускаться меньше 0
— сумма балансов не должна меняться
— транзакции параллельные
Re[8]: Зачем реляционные БД...в небольших проектах?
Хорошо что добавили. Проблема только в том, что такой вид транзакционности не обеспечивает честную изоляцию. Например она не поможет не продать два билета на одно место.
