Здравствуйте, _ABC_, Вы писали:

_AB>С логической точки зрения мало чем отличается от оперативной памяти, но религиозное нарушение есть, конечно.

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

Здравствуйте, _ABC_, Вы писали:

_AB>Э-э-э... Да вообще нет особой разницы с тестами другого кода, вроде как?

Т.е. ты вызываешь хранимки из своего кода?

_AB>В чём разница с автотестированием, допустим, проекта на .Net Core?

В скорости, удобстве, что никакие девопсы не нужны.

_AB>Т.е., заголовок твоей темы не соответствует содержанию твоей головы?

Т.е. в теме не только это обсуждается.

Здравствуйте, mogadanez, Вы писали:


M>он имеет ввиду если именно бизнес-логика в хранимках
M>если ее замокать — часть логики будет непротестирована

Даже необязательно в хранимках, логка может быть инкорпорирована прямо в структуру данных. Скажем, обычный composite unique key это или cascade delete это уже логика. Основные ошибки именно в таких местах и прячутся. Поэтому чтобы сделать тестируемый код, приходится либо не пользоваться никакаими возможностями СУБД кроме самых базовых, либо городить в тестовой системе моков еще одну имплементацию СУБД, либо забить на юнит тесты и сосредоточиться на функциональных тестах.

Здравствуйте, IncremenTop, Вы писали:

IT>Ладно, черт с этим — но зачем все лепят реляционные бд в небольших проектах не из мира финтеха, где acid не нужен? За последние годы видел реляционки даже там, где уже совсем неудобно — даже для хранения данных привязанных ко времени. Такое ощущение, что виноваты ВУЗы, которые почти гвоздями прибили в головы, что база = реляционная.

Большинство разработчиков просто не умеют работать с другими хранилищами данных кроме СУБД. Для них даже картинки в файлах хранить это уже rocket science. А когда они все же это делают, они настолько боятся ошибиться что принимают очень странные решения в духе "мы вообще никогда ничего не будем удалять, только добавлять новое"

Здравствуйте, Sinclair, Вы писали:

S>В Монге у меня возникает иллюзия, что всё это делать не надо. Просто нужно написать у себя в коде проверку, типа "если у книги есть .author — то хорошо, а если есть includedBooks — то это сборник".
S>В итоге через пять релизов у меня каждый "запрос" — это спагетти из вот таких if-ов, которые вообще непонятны новому разработчику в команде. Типа "нафига тут эта формула, зачем предполагать, что название — это book.Name || book.includedBooks[0].name?

Это, скорее, незнание приемов эффективной организации работы с документными базами данных. Для РСУБД у тебя есть хотя бы нормальные формы и реляционная алгебра, а для документных баз нужно свою голову включать. Причем, со стороны кода у тебя же не возникает проблем со спагетти из if-ов. Скорее всего ты думаешь как-то так: "Ага, у нас есть атомарные объект продаж "книга" и контент. Причем у книги может быть несколько блоков контента, у каждого свое название и автор. И у книги может быть свое, отдельное название и автор-составитель. Вроде ясно, давай рефакторить". Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.

Конкретно здесь бы помогло следованием принципам разумной интеграции:
1. Все API за пределы зоны контроля разработчика версионируются, без исключений. Сохранение данных в хранилище это API.
2. Для каждой версии API есть отражение в коде.
3. На вход система обязана принимать любые данные, на выход отдавать только правильные

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

Здравствуйте, IncremenTop, Вы писали:


IT>За распределенный монолит надо увольнять из профессии, а тут еще хуже — распределенный монолит с хранимками. Франкенштейн собственной персоной.

а что не так с распределенным монолитом?

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Почему неудобно? Очень удобно. Специализированные time series db ничуть не более удобны, их плюс не в удобстве, а в том что они жрут в хайлоаде меньше ресурсов. Но небольшие проекты это, как правило, и небольшая нагрузка, на которой особой разницы между RDBMS и TSDB по ресурсам нет, а зрелость, развитые средства и богатый функционал первых остается.

у TSDB часто есть функционал, которого нет у RDBMS, например интеграция со всякими коллекторами данных, поддержка графаны и тд, плюс, жрут меньше они не в хайлоаде а в принципе, для нормальной TSDB несколько десятков тысяч вставок в секунду это ничто (0% утилизация цпу), а для реляционной субд это уже хайлоад

Здравствуйте, Miroff, Вы писали:

M>Это, скорее, незнание приемов эффективной организации работы с документными базами данных. Для РСУБД у тебя есть хотя бы нормальные формы и реляционная алгебра, а для документных баз нужно свою голову включать.
В этом-то и риск.
M>Причем, со стороны кода у тебя же не возникает проблем со спагетти из if-ов. Скорее всего ты думаешь как-то так: "Ага, у нас есть атомарные объект продаж "книга" и контент. Причем у книги может быть несколько блоков контента, у каждого свое название и автор. И у книги может быть свое, отдельное название и автор-составитель. Вроде ясно, давай рефакторить". Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.
Почему же? Вполне себе срабатывает — мы "прикладной" код так и так рефакторим. А дальше остаётся вопрос: а с данными что делать?

M>Конкретно здесь бы помогло следованием принципам разумной интеграции:
M>1. Все API за пределы зоны контроля разработчика версионируются, без исключений. Сохранение данных в хранилище это API.
M>2. Для каждой версии API есть отражение в коде.
M>3. На вход система обязана принимать любые данные, на выход отдавать только правильные

M>Таким образом я бы объявил версию v2 API хранилища данных, отрефакторил модель и прописал в коде правила конверсии v1 в v2.
Совершенно верно. Я привёл вам пример "правила конверсии" v1 в v2, только очень убогого. Да, кстати, вы всегда добавляете в объекты, хранимые в монге поле "версия схемы документа"?
Если нет — то как вы отличаете v1 от v2?
M>Код можно покрывать тестами, включая тесты на инвариант v1->v2->v1. К тому же у меня всегда останется гибкость, оставить в хранилище данные v1 и v2 или запустить миграцию v1 в v2.
Если вы сели делать миграцию, то вы делаете миграцию. Единственная разница в РСУБД и NoSQL — это в том, что первая бьёт вас по рукам за попытки сделать миграцию неверно. Неопытные разработчики на это обижаются.
Кстати, монга уже умеет многодокументные транзакции? Т.е. могу ли я сделать конверсию v1->v2 "на горячую", с гарантированной целостностью изменений?
Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
Особенно здорово, когда схема меняется не просто как "заменить author на author[]", а как "заменить book[i] на ObjectRef()".

Здравствуйте, Gt_, Вы писали:

Gt_>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

А с чего это она выиграет у промышленной рсубд?

Здравствуйте, _ABC_, Вы писали:

IT>>Чтобы аналогичное сделать для кода на sql — уже надо извращаться.
_AB>Почему? Работа идет в той же самой студии, в том же самом гите, можно создавать точно так же пул реквесты, запросы на код ревью и т.д. В чём разница-то?

Человек просто плохо знаком с RDBMS и с SSDT в частности, поэтому у вас разговор напоминает разговор слепого с глухим.

Здравствуйте, Sinclair, Вы писали:

S>Почему же? Вполне себе срабатывает — мы "прикладной" код так и так рефакторим. А дальше остаётся вопрос: а с данными что делать?

Так в том и фишка документных БД что данные это и есть код

S>Совершенно верно. Я привёл вам пример "правила конверсии" v1 в v2, только очень убогого. Да, кстати, вы всегда добавляете в объекты, хранимые в монге поле "версия схемы документа"?

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

S>Если вы сели делать миграцию, то вы делаете миграцию. Единственная разница в РСУБД и NoSQL — это в том, что первая бьёт вас по рукам за попытки сделать миграцию неверно. Неопытные разработчики на это обижаются.

Это не миграция, а конверсия. Тут есть существенная разница, миграция подразуменвает что мы меняем данные, а конверсия что мы меняем интерфейсы доступа к данным. И когда мы делаем конверсию, нам помогает вся мощь инструментов разработчика начиная от компилятора и заканчивая автотестами с помощью фаззеров.

S>Кстати, монга уже умеет многодокументные транзакции? Т.е. могу ли я сделать конверсию v1->v2 "на горячую", с гарантированной целостностью изменений?

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

S>Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
S>Особенно здорово, когда схема меняется не просто как "заменить author на author[]", а как "заменить book[i] на ObjectRef()".

На практике, достаточно быстро появляет политика версионирования. "Поддерживаем последние 2 версии, в течение месяца после релиза в фоновом режиме конвертируем v1 в v2, в следующем релизе выкашиваем v1 из кодовой базы".

Gt_>>достать по ключу, да, монга выиграет. там где нет бизнес логики имеет смысл, лайки считать форумы, но чем сложнее логика тем хуже перформит. в бигдате монги нет от слова совсем, а массивно параллельный postgres (greenplum) присутствует. потому в ентерпрайзе тучи массивно параллельных nosql баз, но не монга.

S>А с чего это она выиграет у промышленной рсубд?

потому что монга сильно примитивней, не будет разбора SQL и поиска его в library cache, не будет оптимизатора, строящего план запроса.

Gt_

Здравствуйте, Miroff, Вы писали:

M>Большинство разработчиков просто не умеют работать с другими хранилищами данных кроме СУБД. Для них даже картинки в файлах хранить это уже rocket science. А когда они все же это делают, они настолько боятся ошибиться что принимают очень странные решения в духе "мы вообще никогда ничего не будем удалять, только добавлять новое"

M>Для них даже картинки в файлах хранить это уже rocket science.

И они совершенно правы. Именно поэтому так популярен S3, CloudFront и прочие CDN

Files are hard

https://danluu.com/file-consistency/

Здравствуйте, chaotic-kotik, Вы писали:

CK>у TSDB часто есть функционал, которого нет у RDBMS, например интеграция со всякими коллекторами данных, поддержка графаны и тд, плюс, жрут меньше они не в хайлоаде а в принципе, для нормальной TSDB несколько десятков тысяч вставок в секунду это ничто (0% утилизация цпу), а для реляционной субд это уже хайлоад

при выборе надо оценивать не только скорость вставок, а все имеющиеся use cases.
например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

еще в TSDB трудно менять данные, если сразу не предусмотрел поле в контексте или требования поменялись — то надо достаточно сложный мигрейт делать. в RDBMS чаще всего можно отбиться усложнением запроса, хотя бы на время

Здравствуйте, mogadanez, Вы писали:

M>например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

это какие?

Здравствуйте, chaotic-kotik, Вы писали:

CK>Здравствуйте, mogadanez, Вы писали:

M>>например мне нужно было не только быстро писать, но и быстрые запросы по записанным данным. на этом TSDB слились.

CK>это какие?
да не то что бы особо сложное чтото
чтонить наподобие

  from(bucket: "events")
    |> range(start: -3y)
    |> filter(fn: (r) => r["_measurement"] == "subject_event")
    |> filter(fn: (r) => r["company"] == "2")
    |> filter(fn: (r) => r["event_type"] == "5" or r["event_type"] == "11" )
    |> group(columns: [ "event_type"])
    |> unique(column: "user_subject")
    |> count(column:"_value")

TSDB быстр если ограничивать при запросе временной интервал. те они какбы заточены под UI где есть "временное окно" и там как бы подразумевается что если ты работаешь по данным за долгий период — жди

Здравствуйте, IncremenTop, Вы писали:

IT>С логической точки зрения юнит-тесты должны быть дешевыми, чтобы разработчик их и писал постоянно, и самое главное — запускал.
Какая разница, создать mock-объект, или заполнить фейк-данными таблицу?
Один раз написал скрипт — потом запускаешь себе сколько угодно.

Здравствуйте, IncremenTop, Вы писали:

IT>Т.е. ты вызываешь хранимки из своего кода?
Когда именно?
Если мы говорим про тесты, то у БД проекта есть свои unit-тесты, отдельные от .Net кода.
Погугли sql server unit tests уже...

IT>В скорости, удобстве, что никакие девопсы не нужны.
Э-э-э...
Для настройки CI/CD не нужны девопсы? Ну, тогда нужен кто-то выполняющих их роль и обладающий соответствующими знаниями, всё равно.

И если человек обладает знаниями, как создать CI/CD для .Net Core проекта, он очень быстро разберётся и с юнит тестами для SQL Server, я тебе это гарантирую из собственного опыта, т.к. там разницы вообще практически нет. Нет никакой разницы в скорости, удобстве.

Здравствуйте, Miroff, Вы писали:

M>Но почему-то ровно та же цепочка рассуждений в случае монги не срабатывает.
В такой цепочке рассуждений данные надо будет мигрировать из старой версии в новую. В то время, как ТС утверждает, что не надо. Об этом и речь, собственно.

Здравствуйте, Miroff, Вы писали:
M>Разумеется, в этом суть версионирования и состоит. В РСУБД обычно где-то есть костыльная табличка с номерами версий, а тут версия есть у объектов, а не у хранилища в целом. Думаю, преимущества версионирования объектов перед версионированием всего хранилища подхода достаточно очевидны, чтобы их перечислять.
M>Это не миграция, а конверсия. Тут есть существенная разница, миграция подразуменвает что мы меняем данные, а конверсия что мы меняем интерфейсы доступа к данным. И когда мы делаем конверсию, нам помогает вся мощь инструментов разработчика начиная от компилятора и заканчивая автотестами с помощью фаззеров.
Похоже, мы вышли за пределы моей компетентности.
Можете привести пример кода конверсии с пояснением, как он работает?

M>Чтение-запись документа атомарны и этого достаточно, поскольку не требуется менять всю базу разом.
Ну, для рассматриваемого примера — наверное, достаточно. А что делать в случаях, когда мы превращаем строковый атрибут "автор" в ObjectRef на документ "Автор", мне пока непонятно.
S>>Если вы решили оставить в базе и v1 и v2, то постепенно у вас там v1, v2, v3, v4, v5 и так далее, и вы тащите с собой код "конверсии".
M>На практике, достаточно быстро появляет политика версионирования. "Поддерживаем последние 2 версии, в течение месяца после релиза в фоновом режиме конвертируем v1 в v2, в следующем релизе выкашиваем v1 из кодовой базы".
Подскажите, а откуда вы знаете, что v1 в базе уже нету?