каталогизация баз данных, вопрос по терминологии - Базы данных

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

B>Что такое RDBMS и NoSQL — это типы баз данных или виды или что то еще ?

Если где-то и есть определение, что такое "вид базы данных" и чем он отличается от столь же чётко определённого "типа базы данных", то я его не встречал. И, думаю, коллеги тоже не встречали.

B>по какому принципу строить каталог ?

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

Пожалуй, наиболее часто используемая классификация — по модели данных, положенной в основу DBMS.

B>Что такое RDBMS и NoSQL

RDBMS — это базы данных, построенные на основе реляционной модели. Простым языком — основным объектом является прямоугольная таблица.
NoSQL — это маркетинговый буллшит, объединяющее название для попыток сделать "лучше чем реляционные" DBMS.

B>Реляционная

RDBMS.

B>Сетевая

DBMS, построенные на основе сетевой модели данных. Простым языком — данные представлены в виде графа.

B>Иерархическая

DBMS, построенные на основе иерархической модели данных. Частный случай сетевых, в котором граф вырожден в дерево.

B>Объектная и объектно-ориентированная

В общем-то маркетинговый буллшит. DBMS, модель данных в которой заточена под операции с объектами в смысле ООП. По сути — сетевая или иерархическая DBMS с синтаксическим сахаром.

B>Объектно-реляционная

Маркетинговый буллшит, придуманный Oracle, когда шумиха вокруг объектных БД приняла заметные масштабы. Реляционная БД с некоторым синтаксическим сахаром для "типа ООП".

B>Функциональная.

Хз. Никогда не встречал.

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

Большое спасибо за ваш развернутый ответ !

Все таки хотел бы чуть подробней остановиться на классификации по модели данных и NoSQL.

Какая модель данных положена в основу NoSQL ? Или там разные конкретные реализации имеют свои модели, например OrientDB это Сетевая модель ?

А если взять к примеру Cassandra либо Redis, либо MongoDB. Какие это модели ?

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

B>>Функциональная.
S>Хз. Никогда не встречал.

Ну как же, если есть функциональные языки программирования, то должны, просто обязаны появиться и функциональные БД.

Наверняка уже есть пара толстых книжек про них.

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

B>Какая модель данных положена в основу NoSQL ?
Тебе же ответили, что NoSQL — это маркетинговый булшит (bullshit). Они даже не знают как это расшифровывается, кто-то говорит, что это — NO SQL; другие — Not Only SQL.
А ты хочешь найти там единую модель данных.

B>А если взять к примеру Cassandra либо Redis, либо MongoDB. Какие это модели ?
Идешь на Википедею или на сайт "производителя" и читаешь, к какой модели данных они считают это относится.

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

Коротко о главном:
0. Сначала баз данных не было.
1. Потом появились "базы данных", в которых, грубо говоря, была 1 таблица вида ключ:значение; с операциями "найти данные по ключу" и "просмотреть данные по ключам".
2. Потом их доработали до иерархических — т.е. помимо ключ:значение есть ещё и ключ:детиключа. (В современном мире остались два представителя этого вида: реестр Windows (потупее) и Active Directory (поумнее).) Примерно в это время появился сам термин "СУБД", т.к. от БД специального назначения перешли к более абстрактным инструментам.
3. Потом их доработали до сетевых — когда ключ может иметь более 1 "родительского" ключа.
4. Потом пришёл Кодд и показал, что реляционная СУБД может оптимально выполнять все операции, оптимальные для этих трёх типов СУБД. И ещё вагон и маленькую тележку операций, на которых любой из этих трёх типов дохнет.

5. Потом на территорию реляционной империи пришли варвары, которые решили, что поставить компьютер с RAM размером в 1000 раз больше, чем типичный объём диска врёмен Кодда, будет дешевле, чем научить пару инженеров пользоваться SQL. И предложили вернуться к п.1 — базам данных "доиерархического" образца. Основной маркетинговый хайп — это "вам не нужно мучиться с SQL". Для нас, поколения 90х, это звучит примерно как "ешьте лебеду — теперь вам не нужно мучиться со стейками".

B>по какому принципу строить каталог ?
По принципу копи-пейста из википедии.

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

S>5. Потом на территорию реляционной империи пришли варвары, которые решили, что поставить компьютер с RAM размером в 1000 раз больше, чем типичный объём диска врёмен Кодда, будет дешевле, чем научить пару инженеров пользоваться SQL. И предложили вернуться к п.1 — базам данных "доиерархического" образца. Основной маркетинговый хайп — это "вам не нужно мучиться с SQL". Для нас, поколения 90х, это звучит примерно как "ешьте лебеду — теперь вам не нужно мучиться со стейками".

Справедливости ради, варвары пришли со вполне здравой идеей: зачем вам УНИВЕРСАЛЬНЫЙ RDBMS если у вас конкретное приложение с конкретными задачами под которые можно заточить специализированное решение выиграв в производительности за счет отказа от универсальности. Причем сказали они это в имея в виду распределенные системы в которых CAP теорема стоит в полный рост.

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

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

S>>5. Потом на территорию реляционной империи пришли варвары, которые решили, что поставить компьютер с RAM размером в 1000 раз больше, чем типичный объём диска врёмен Кодда, будет дешевле, чем научить пару инженеров пользоваться SQL. И предложили вернуться к п.1 — базам данных "доиерархического" образца. Основной маркетинговый хайп — это "вам не нужно мучиться с SQL". Для нас, поколения 90х, это звучит примерно как "ешьте лебеду — теперь вам не нужно мучиться со стейками".

M>Справедливости ради, варвары пришли со вполне здравой идеей: зачем вам УНИВЕРСАЛЬНЫЙ RDBMS если у вас конкретное приложение с конкретными задачами под которые можно заточить специализированное решение выиграв в производительности за счет отказа от универсальности. Причем сказали они это в имея в виду распределенные системы в которых CAP теорема стоит в полный рост.

Это тоже маркетинговый буллшит, причем в квадрате. Заранее никто не знает всех деталей конкретного приложения, поэтому и используют универсальные средства для разработки (языки, субд). Вы же прекрасно понимаете, что используя специализированный яызк для определенного класса задач можно быстро упереться в его ограничение, если ваша задача слегка выйдет за рамки этого класса. Тоже самое с базами данных. С СУБД ситуация еще хуже, ибо код переписать легко, а мигрировать с одной СУБД на другую это боль.

Но маркетологи NoSQL смогли вас убедить что в некоторых задачах имеет смысл пользоваться "базами данных доиерархического образца" (с), получив от этого какие-то преимущества (хотя в реальной жизни этих преимуществ мало кто видел). А чтобы оправдать недостатки начали использовать CAP теорему, которая верна для абстрактной системы, практически не существующей в реальном мире. Да еще и извратили её понимание, пользуясь фонетическим сходством терминов CAP с другими областями. Вот подробнее — http://habrahabr.ru/post/231703/

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

M>Справедливости ради, варвары пришли со вполне здравой идеей: зачем вам УНИВЕРСАЛЬНЫЙ RDBMS если у вас конкретное приложение с конкретными задачами под которые можно заточить специализированное решение выиграв в производительности за счет отказа от универсальности. Причем сказали они это в имея в виду распределенные системы в которых CAP теорема стоит в полный рост.
Вот как раз с этим пришли не варвары, а вполне вменяемые люди. А вот попытки всунуть NoSQL в качестве general-purpose DBMS делают именно варвары.
CAP-теорема — это вообще отстой, типичная попытка подвести наукообразие под народные глупости.
Любые рассуждения, в которыхa availability принимает булевые значения — антинаучный булшит. Взрослые дяди должны быть в курсе того, что минимально полезная в инженерном деле availability — это величина с плавающей запятой. Более того, даже такая трактовка availability малополезна — в реальности нужно использовать хотя бы распределение характерных времён получения success response и частот получения failure response, т.к. ежедневный простой в 5 минут вовсе не эквивалентен ежегодному простою в 1 сутки.

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

G>Тоже самое с базами данных. С СУБД ситуация еще хуже, ибо код переписать легко, а мигрировать с одной СУБД на другую это боль.

Это у вас в реляционном мире все данные лежат в одной большой помойке и тебе почему-то кажется что и NoSQL работает так же. На самом деле умные люди используют для каждого типа данных свое хранилище: картинки в ФС, кэши в памяти, мясо в РСУБД с ОРМом. У них нет боли выкинуть Memcached и воткнуть вместо него Redis или выкинуть MySQL и воткнуть Oracle.

G>Но маркетологи NoSQL смогли вас убедить что в некоторых задачах имеет смысл пользоваться "базами данных доиерархического образца" (с), получив от этого какие-то преимущества (хотя в реальной жизни этих преимуществ мало кто видел).

Ну не знаю, я видел. Задача: при выборе баннера для показа пользователю нужно обеспечить частоту не чаще N показов одного баннера в единицу времени. Система распределенная, пользователей весь интернет. Т.е. требуется хранить сотни миллионов коротких сессий, по одной для каждого пользователя. Что РСУБД может предложить в качестве решения? Без новомодных NoSQL фишечек, чистый хардкорный РСУБД на основе реляционной теории.

NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.

G>А чтобы оправдать недостатки начали использовать CAP теорему, которая верна для абстрактной системы, практически не существующей в реальном мире. Да еще и извратили её понимание, пользуясь фонетическим сходством терминов CAP с другими областями. Вот подробнее — http://habrahabr.ru/post/231703/

По-моему ты споришь со своими тараканами. CAP теорема говорит о том что невозможно одновременно C, A и P. Ты говоришь что гарантии С, А и Р в формулировке теоремы слишком слабые. Классно. Если на слабых гарантиях это невозможно, то и на сильных гарантиях это и подавно невозможно. Если не вдаваться в крайние ограничения, это замечательно соотносится с практикой и тестами на кошках.

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

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

G>>Тоже самое с базами данных. С СУБД ситуация еще хуже, ибо код переписать легко, а мигрировать с одной СУБД на другую это боль.

M>Это у вас в реляционном мире все данные лежат в одной большой помойке и тебе почему-то кажется что и NoSQL работает так же. На самом деле умные люди используют для каждого типа данных свое хранилище: картинки в ФС, кэши в памяти, мясо в РСУБД с ОРМом.

Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.

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

M>У них нет боли выкинуть Memcached и воткнуть вместо него Redis или выкинуть MySQL и воткнуть Oracle.
Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.

G>>Но маркетологи NoSQL смогли вас убедить что в некоторых задачах имеет смысл пользоваться "базами данных доиерархического образца" (с), получив от этого какие-то преимущества (хотя в реальной жизни этих преимуществ мало кто видел).

M>Ну не знаю, я видел. Задача: при выборе баннера для показа пользователю нужно обеспечить частоту не чаще N показов одного баннера в единицу времени. Система распределенная, пользователей весь интернет. Т.е. требуется хранить сотни миллионов коротких сессий, по одной для каждого пользователя. Что РСУБД может предложить в качестве решения? Без новомодных NoSQL фишечек, чистый хардкорный РСУБД на основе реляционной теории.
Шутишь?

insert bannerhits (userid, bannerid) 
values (@userid, 
    (select top 1 bannerid 
     from bannerhits h
     left join banners b on h.bannerid = b.id 
                         and h.userid = @userid 
                         and h.lastaccess between @periodstart and @periodend
     group by b.id
     having count(h.lastaccess) < @maxShowPerFrame )
     order by newid()) 
output inserted.bannerid

Индекс на bannerhits по userid, lastaccess desc
Обязательно сделать partition по userid, 2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.

M>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.

G>>А чтобы оправдать недостатки начали использовать CAP теорему, которая верна для абстрактной системы, практически не существующей в реальном мире. Да еще и извратили её понимание, пользуясь фонетическим сходством терминов CAP с другими областями. Вот подробнее — http://habrahabr.ru/post/231703/

M>По-моему ты споришь со своими тараканами. CAP теорема говорит о том что невозможно одновременно C, A и P. Ты говоришь что гарантии С, А и Р в формулировке теоремы слишком слабые. Классно. Если на слабых гарантиях это невозможно, то и на сильных гарантиях это и подавно невозможно. Если не вдаваться в крайние ограничения, это замечательно соотносится с практикой и тестами на кошках. Ты неправильно понял. Действительно невозможно одновременно C, A и P. Но самое интересное, что P в реальной жизни не случается, A в понимании CAP не нужно, а C — дает слабые гарантии. Поэтому сравнивать NoSQL и SQL и говорить о CAP — глупость. ACID гораздо ближе к реальности, чем CAP и BASE.

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

G>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.

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

G>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.

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

G>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.

Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.

G>Шутишь?

Что-то такое я и предполагал

G>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.

Решение на KV хранилище выдает 10-30к инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр

M>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.

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

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

S>Вот как раз с этим пришли не варвары, а вполне вменяемые люди. А вот попытки всунуть NoSQL в качестве general-purpose DBMS делают именно варвары.

Единственное NoSQL хранилище которое пытаются впихнуть в этом качестве, это MongoDB и то с оговорками "для веба". Если сравнивать не со взрослыми БД а с типичной для веба MySQL используемой на 10% функционала в силу использования ORM, то такое решение может даже быть оправданным.

S>CAP-теорема — это вообще отстой, типичная попытка подвести наукообразие под народные глупости.
S>Любые рассуждения, в которыхa availability принимает булевые значения — антинаучный булшит. Взрослые дяди должны быть в курсе того, что минимально полезная в инженерном деле availability — это величина с плавающей запятой. Более того, даже такая трактовка availability малополезна — в реальности нужно использовать хотя бы распределение характерных времён получения success response и частот получения failure response, т.к. ежедневный простой в 5 минут вовсе не эквивалентен ежегодному простою в 1 сутки.

Я может неправильно понимаю CAP теорему, но я всегда считал что availability в контексте CAP это отсутствие простоев на синхронизацию данных между узлами. Если по рабоче-крестьянски, то ни один узел никогда не блокируется на синхронизацию. Это не эквивалентно general purpose availability. Соответственно consistency означает что данные измененные в одном узле другие узлы будут отдавать уже измененными при следующем же запросе. Partition tolerance в контексте CAP означает что при отказе одной из партиций, данные всегда можно получить из другой партиции.

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

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

G>>Как физически хранятся данные — детали конкретной субд. MS SQL имеет тип filetable — по сути файлы и папки для пользователя выглядит как таблица и можно работать как через SQL, так и через WinAPI.

M>Можно и так, особенно если вам плевать как будет развиваться приложение после того как вы его сдадите.

Какие потенциальные проблемы вы видите? Что мешает в любой момент откзаться от filetable и хранить файлы еще где-то если вдруз filetable перестанет хватать? А пока filetable хватает, то зачем лепить еще что-то?

G>>Так что для каждого типа свое хранилище — скорее вынужденная мера, чтобы обойти ограничения хранилища, чем признак ума. А иногда стремление "для каждого типа данных свое хранилище" приводит к неоправданному увеличению затрат на разработку.

M>Ну боль-то в основном у тех кто использует хранилище общего назначения для всего. Внезапно оказывается что картинки нужно выносить в CDN, файлы бэкапить отдельно от базы, а кэша вообще не бэкапить.
CDN это другой слой, никак не коррелирует с хранилищем. Если CDN навязывает вам работу с хранилщем, то это хреновый CDN и его стоит выкинуть.
Кеш это как бы тоже другой слой, нет смысла объединять кеш и базу. Точно также если вам кеш навязывает как работать с данными, то это хреновый кеш и его надо выкинуть.

G>>Потому что это замена более слабой системы на более сильную А вот заменить оракл на mysql это боль. А замена MS SQL на key-value хранилище — аццкая боль.
M>Зачем кому-то в здравом уме менять весь MS SQL на KV хранилище? О_о Это все равно что пытаться заменить колесо ниткой.
Заменять почти никто в здравом уме не будет, в 99,99% случаев это не оправдано. Но вот на моменте старта разработки некоторые делают выбор в сторону NoSQL, хотя это также неоправданно, потому что повышение трудозатрат будет не меньше чем при миграции.

G>>Шутишь?

M>Что-то такое я и предполагал

G>>2-3 тыщи инсертов в секудну выдержит на быстром диске, масштабируется добавлением дисков и партиций.

M>Решение на KV хранилище выдает 10-30 инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр

Прости но это смешно. Что он делает 100 мс на один инсерт? Даже 30мс это слишком дофига. У меня LocalDB быстрее работает.

M>>>NoSQL на эту тему предлагает забить на P и использовать KV хранилище, а список всех возможных баннеров джойнить со списком всех просмотренных баннеров в памяти прямо из приложения.
G>>если durability и масштабирование не нужно вообще, то хорошее решение. Но обычно нужно и то и другое.

M>В данном конкретном случае отказом партиции можно пренебречь. Оттого что ограничение частоты показа для некоторых пользователей сломается, никто не умрет.
То есть NoSQL предлагает более медленное и менее надежное решение? Где же преимущества?

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

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

S>>Вот как раз с этим пришли не варвары, а вполне вменяемые люди. А вот попытки всунуть NoSQL в качестве general-purpose DBMS делают именно варвары.

M>Единственное NoSQL хранилище которое пытаются впихнуть в этом качестве, это MongoDB и то с оговорками "для веба". Если сравнивать не со взрослыми БД а с типичной для веба MySQL используемой на 10% функционала в силу использования ORM, то такое решение может даже быть оправданным.
Монга — говнище полнейшее. На реальных задачах тормозит не меньше postgres, требует больше памяти, часто делает corruption и теряет при падении, collection-level лок на запись и отсутствие кросс-документных транзакций делает монгу бесполезной чуть более чем полностью на реальных задачах. Вот пост в тему — http://habrahabr.ru/post/231213/
Монга сегодня — "тихая гавань" для тех, кто не осилил SQL.

S>>CAP-теорема — это вообще отстой, типичная попытка подвести наукообразие под народные глупости.
S>>Любые рассуждения, в которыхa availability принимает булевые значения — антинаучный булшит. Взрослые дяди должны быть в курсе того, что минимально полезная в инженерном деле availability — это величина с плавающей запятой. Более того, даже такая трактовка availability малополезна — в реальности нужно использовать хотя бы распределение характерных времён получения success response и частот получения failure response, т.к. ежедневный простой в 5 минут вовсе не эквивалентен ежегодному простою в 1 сутки.

M>Я может неправильно понимаю CAP теорему, но я всегда считал что availability в контексте CAP это отсутствие простоев на синхронизацию данных между узлами. Если по рабоче-крестьянски, то ни один узел никогда не блокируется на синхронизацию. Это не эквивалентно general purpose availability. Соответственно consistency означает что данные измененные в одном узле другие узлы будут отдавать уже измененными при следующем же запросе. Partition tolerance в контексте CAP означает что при отказе одной из партиций, данные всегда можно получить из другой партиции.

Ты правильно понимаешь. С таким определением availability достигается тем, что все узлы смотрят в один "мастер-узел", если разделений не случается (а в локальной сети можно считать что не случается), то все ОК.
Но с реальным availability, который измеряется в процентах аптайма за период, это никак не связано. Более того, даже отсутствие availability с точки зрения CAP можен не приводить к падению avaulability с потребительской точки зрения.

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

G>Какие потенциальные проблемы вы видите? Что мешает в любой момент откзаться от filetable и хранить файлы еще где-то если вдруз filetable перестанет хватать? А пока filetable хватает, то зачем лепить еще что-то?

Разные стратегии отдачи данных. На FS можно натравить nginx, на filetable нельзя. Разные стратегии бэкапа, часто файлы вообще не нужно бэкапить в силу конского объема. Разное влияние дефрагментации при удалении данных, не знаю насколько это критично для MS SQL.

G>CDN это другой слой, никак не коррелирует с хранилищем. Если CDN навязывает вам работу с хранилщем, то это хреновый CDN и его стоит выкинуть.

CDN максимально эффективно работает при прямом доступе к хранилищу минуя слой сервера приложений и слой хранилища данных. Или уже есть CDN умеющие отдавать файлы из RDBMS?

G>Кеш это как бы тоже другой слой, нет смысла объединять кеш и базу. Точно также если вам кеш навязывает как работать с данными, то это хреновый кеш и его надо выкинуть.

Кэши это 90% использований NoSQL. А дальше происходит логический переход: если приложение 99% времени работает только с кэшем, может вместо РСУБД взять персистентный кэш?

G>Заменять почти никто в здравом уме не будет, в 99,99% случаев это не оправдано. Но вот на моменте старта разработки некоторые делают выбор в сторону NoSQL, хотя это также неоправданно, потому что повышение трудозатрат будет не меньше чем при миграции.

Никто не выбирает между RDBMS и KV, максимум между документными и реляционными БД.

M>>Решение на KV хранилище выдает 10-30 инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр

G>Прости но это смешно. Что он делает 100 мс на один инсерт? Даже 30мс это слишком дофига. У меня LocalDB быстрее работает.

10-30k разумеется

G>То есть NoSQL предлагает более медленное и менее надежное решение? Где же преимущества?

Более быстрое и менее надежное, разумный tradeoff.

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

G>Монга — говнище полнейшее. На реальных задачах тормозит не меньше postgres, требует больше памяти, часто делает corruption и теряет при падении, collection-level лок на запись и отсутствие кросс-документных транзакций делает монгу бесполезной чуть более чем полностью на реальных задачах. Вот пост в тему — http://habrahabr.ru/post/231213/
G>Монга сегодня — "тихая гавань" для тех, кто не осилил SQL.

9 из 10 веб проектов представляют собой никому не нужное унылое говно которое никогда не увидит ни реальных задач, ни реальных нагрузок. Зачем им что-то более производительное чем монго? А вот плюсы которые монга дает при разработке довольно ощутимы. Пихать объекты в базу as is (в том числе без всякой валидации!) очень удобно и быстро.

G>Ты правильно понимаешь. С таким определением availability достигается тем, что все узлы смотрят в один "мастер-узел", если разделений не случается (а в локальной сети можно считать что не случается), то все ОК.

В смысле все клиенты пишут и читают из одного мастер-узла? Так это не распределенная система, уперлись в мастер — сушим весла.

G>Но с реальным availability, который измеряется в процентах аптайма за период, это никак не связано. Более того, даже отсутствие availability с точки зрения CAP можен не приводить к падению avaulability с потребительской точки зрения.

Разумеется.

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

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

G>>Какие потенциальные проблемы вы видите? Что мешает в любой момент откзаться от filetable и хранить файлы еще где-то если вдруз filetable перестанет хватать? А пока filetable хватает, то зачем лепить еще что-то?

M>Разные стратегии отдачи данных. На FS можно натравить nginx, на filetable нельзя.
Пффф. IIS будет отдавать файлы с диска быстрее любого nginx.

M>Разные стратегии бэкапа, часто файлы вообще не нужно бэкапить в силу конского объема. Разное влияние дефрагментации при удалении данных, не знаю насколько это критично для MS SQL.
Открою тайну — SQL Server умеет беапить файловые группы по-отдельности. Не обязательно надо делать полный бекап каждый раз.

G>>CDN это другой слой, никак не коррелирует с хранилищем. Если CDN навязывает вам работу с хранилщем, то это хреновый CDN и его стоит выкинуть.
M>CDN максимально эффективно работает при прямом доступе к хранилищу минуя слой сервера приложений и слой хранилища данных.
Зачем сервер приложений чтобы отдавать файлы? делаешь отдельный сайт на IIS на отдельном hostname, который смотрит в шаренную папку filetable на субд и отдает из нее файлы. Или для полного счастья ставишь iis на сервер бд и отдаешь файлы прямо с диска, главное размеры кешей настроить. А к этим веб-серверам уже обращается CDN.

M>Или уже есть CDN умеющие отдавать файлы из RDBMS?
Не знаю, это не нужно. Для CDN достаточно по HTTP забирать, а отдать файл как можно быстрее по HTTP — отлично решаемая задача в MS SQL+IIS (напомню, что работает быстрее nginx в среднем).

G>>Кеш это как бы тоже другой слой, нет смысла объединять кеш и базу. Точно также если вам кеш навязывает как работать с данными, то это хреновый кеш и его надо выкинуть.

M>Кэши это 90% использований NoSQL.
Стоп, кеши это кеши. К долговременному хранилищу кеши отностятся чуть менее, чем никак.

M>А дальше происходит логический переход: если приложение 99% времени работает только с кэшем, может вместо РСУБД взять персистентный кэш?
Неправильный переход, потому что сценарии использования и требования разные. В конце концов кеш всегда можно сбросить и пересобрать. Но если у тебя есть только кеш, то это жопа, у тебя получается перманентно неконсистетный набор данных.

G>>Заменять почти никто в здравом уме не будет, в 99,99% случаев это не оправдано. Но вот на моменте старта разработки некоторые делают выбор в сторону NoSQL, хотя это также неоправданно, потому что повышение трудозатрат будет не меньше чем при миграции.

M>Никто не выбирает между RDBMS и KV, максимум между документными и реляционными БД.
Да без разницы, документные БД позволяют в запросах делать предикаты к частям документов, но на больших объемах это работает хуже SQL, поэтому документные БД почти всегда хорошо работают при выборке по ключу, то есть тоже самое что обычные KV хранилища.

M>>>Решение на KV хранилище выдает 10-30 инсертов в секунду и упирается в CPU, а не в диски. Масштабируется горизонтально шардингом по user_id. Надо будет сравнить разные хранилища на этой задаче и написать статью на хабр

G>>

G>>Прости но это смешно. Что он делает 100 мс на один инсерт? Даже 30мс это слишком дофига. У меня LocalDB быстрее работает.

M>10-30k разумеется
А вот это уже неправдоподобно. Это означает что физической записи на диск не происходит при инсерте (или очень быстрый SSD диск). То есть надежность нулевая.

G>>То есть NoSQL предлагает более медленное и менее надежное решение? Где же преимущества?
M>Более быстрое и менее надежное, разумный tradeoff.
В MS SQL тоже можно delayed durability включить, получатся те же 30к и тоже начнет упираться в процессор.

Так что не зачем городить KV. Преимуществ нет.

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

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

G>>Монга — говнище полнейшее. На реальных задачах тормозит не меньше postgres, требует больше памяти, часто делает corruption и теряет при падении, collection-level лок на запись и отсутствие кросс-документных транзакций делает монгу бесполезной чуть более чем полностью на реальных задачах. Вот пост в тему — http://habrahabr.ru/post/231213/
G>>Монга сегодня — "тихая гавань" для тех, кто не осилил SQL.

M>9 из 10 веб проектов представляют собой никому не нужное унылое говно которое никогда не увидит ни реальных задач, ни реальных нагрузок. Зачем им что-то более производительное чем монго? А вот плюсы которые монга дает при разработке довольно ощутимы. Пихать объекты в базу as is (в том числе без всякой валидации!) очень удобно и быстро.
Это же неправда. В монге надо проверять что коллекция есть. Для монги надо сервак ставить отдельный и базу шринкать (блокирующая операция).
В описанном тобой сценарии рулит SQLite или SQLCE + ОРМ, который умеет генерить схему БД по классам (например EF). Ему не надо будет отдельного сервака, да еще и запросы быстрее работать будут (ибо индексы и все в памяти процесса).

Еще раз повторю — MongoDB это для тех кто не осилил SQL, но считает что нужна отдельная база, а не простая встраиваемая.

G>>Ты правильно понимаешь. С таким определением availability достигается тем, что все узлы смотрят в один "мастер-узел", если разделений не случается (а в локальной сети можно считать что не случается), то все ОК.
M>В смысле все клиенты пишут и читают из одного мастер-узла? Так это не распределенная система, уперлись в мастер — сушим весла.
Никаких проблем — можно сделать непересекающиеся шарды. Так собственно некоторые NoSQL и работают.

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

G>Открою тайну — SQL Server умеет беапить файловые группы по-отдельности. Не обязательно надо делать полный бекап каждый раз.

Рад за вас. Это в базовой версии или нужно специальную лицензию прикупить

G>Зачем сервер приложений чтобы отдавать файлы? делаешь отдельный сайт на IIS на отдельном hostname, который смотрит в шаренную папку filetable на субд и отдает из нее файлы. Или для полного счастья ставишь iis на сервер бд и отдаешь файлы прямо с диска, главное размеры кешей настроить. А к этим веб-серверам уже обращается CDN.
Ну а с файлами на ФС никакого отдельного сервера не нужно.

Прикольная фича иметь с одной стороны ФС, с другой таблицу в базе. Жаль ни в мускуле ни в постгре такого нет.

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

В реальной ситуации кэш далеко не всегда можно пересобрать за обозримое время.

G>А вот это уже неправдоподобно. Это означает что физической записи на диск не происходит при инсерте (или очень быстрый SSD диск).

Именно, запись на диск пакетная и отложенная что позволяет оптимизировать обращения к диску.

G>То есть надежность нулевая.

Не "нулевая", а достаточная в контексте текущей задачи.

G>В MS SQL тоже можно delayed durability включить, получатся те же 30к и тоже начнет упираться в процессор.

Круто. Точно надо будет провести тест.

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

G>Это же неправда. В монге надо проверять что коллекция есть.

Нафига? При добавлении документа в несуществующую коллекцию, она автоматически создается.

G>Для монги надо сервак ставить отдельный и базу шринкать (блокирующая операция).

Нафига? Замечательно живет на одной железке.

G>В описанном тобой сценарии рулит SQLite или SQLCE + ОРМ, который умеет генерить схему БД по классам (например EF). Ему не надо будет отдельного сервака, да еще и запросы быстрее работать будут (ибо индексы и все в памяти процесса).
G>Еще раз повторю — MongoDB это для тех кто не осилил SQL, но считает что нужна отдельная база, а не простая встраиваемая.

Тоже вариант, со своими плюсами и минусами. Плюсы: легче переехать на взрослую СУБД, минусы: нужна схема, нужны миграции, рухнет под нагрузкой сразу и навсегда.

G>Никаких проблем — можно сделать непересекающиеся шарды. Так собственно некоторые NoSQL и работают.

Непересекающиеся шарды — не будет partition tolerance. Можно сделать что-то типа RAID10, когда на один узел одновременно мастер для одного шарда и реплика для другого. Но это не гарантирует consistency в момент переключения с мастера на реплику.

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

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

G>>Открою тайну — SQL Server умеет беапить файловые группы по-отдельности. Не обязательно надо делать полный бекап каждый раз.

M>Рад за вас. Это в базовой версии или нужно специальную лицензию прикупить

В базовой.

G>>Зачем сервер приложений чтобы отдавать файлы? делаешь отдельный сайт на IIS на отдельном hostname, который смотрит в шаренную папку filetable на субд и отдает из нее файлы. Или для полного счастья ставишь iis на сервер бд и отдаешь файлы прямо с диска, главное размеры кешей настроить. А к этим веб-серверам уже обращается CDN.
M>Ну а с файлами на ФС никакого отдельного сервера не нужно.
Ага, и ни ссылочной целостности, ни транзакционности.

M>Прикольная фича иметь с одной стороны ФС, с другой таблицу в базе. Жаль ни в мускуле ни в постгре такого нет.
Ну так не надо пользоваться слабыми СУБД.

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

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

G>>А вот это уже неправдоподобно. Это означает что физической записи на диск не происходит при инсерте (или очень быстрый SSD диск).

M>Именно, запись на диск пакетная и отложенная что позволяет оптимизировать обращения к диску.

G>>То есть надежность нулевая.
M>Не "нулевая", а достаточная в контексте текущей задачи.
На самом деле она стремится к нулю при увеличении нагрузки. Потому что такая система не дает верхней границы потери данных при сбое.
Если этого "достаточно", то можно вообще отказаться от надежного хранения и все держать в кеше. В redis например есть что-то для работы с timeseries.

G>>В MS SQL тоже можно delayed durability включить, получатся те же 30к и тоже начнет упираться в процессор.

M>Круто. Точно надо будет провести тест.

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

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

G>>Это же неправда. В монге надо проверять что коллекция есть.
Хм... раньше не так было.

M>Нафига? При добавлении документа в несуществующую коллекцию, она автоматически создается.

G>>Для монги надо сервак ставить отдельный и базу шринкать (блокирующая операция).
M>Нафига? Замечательно живет на одной железке.
Потому что вся база висит в памяти, а это мешает веб-серверу. Если база меньше 1ГБ, то лучше встраиваемая.

G>>В описанном тобой сценарии рулит SQLite или SQLCE + ОРМ, который умеет генерить схему БД по классам (например EF). Ему не надо будет отдельного сервака, да еще и запросы быстрее работать будут (ибо индексы и все в памяти процесса).
G>>Еще раз повторю — MongoDB это для тех кто не осилил SQL, но считает что нужна отдельная база, а не простая встраиваемая.

M>Тоже вариант, со своими плюсами и минусами. Плюсы: легче переехать на взрослую СУБД, минусы: нужна схема, нужны миграции, рухнет под нагрузкой сразу и навсегда.
EF автоматизирует и схему и миграции, а если будет нагрузка, то переехать на взрослую базу не проблема. Код не поменяется.

G>>Никаких проблем — можно сделать непересекающиеся шарды. Так собственно некоторые NoSQL и работают.

M>Непересекающиеся шарды — не будет partition tolerance.
Да и хрен с ним, все равно все в одной сети стоит.

Здравствуйте, Miroff, Вы писали:
M>Я может неправильно понимаю CAP теорему, но я всегда считал что availability в контексте CAP это отсутствие простоев на синхронизацию данных между узлами.
Вся суть CAP теоремы сводится к трюизму "если компьютер А не подключен к компьютеру Б, то невозможно на компьютере А прочитать данные, записанные в компьютер Б".
Потому что их определение availability — это вообще способность системы ответить на запрос, безо всяких лимитов на время. Вопросы времени они изящно обходят, предполагая бесконечную длительность partitioning.

Здравствуйте, Miroff, Вы писали:
M>CDN максимально эффективно работает при прямом доступе к хранилищу минуя слой сервера приложений и слой хранилища данных. Или уже есть CDN умеющие отдавать файлы из RDBMS?
Это какая-то чушь. CDN работает при доступе к "хранилищу" через HTTP. Считайте его таким умным reverse-proxy. Вы что, полагаете, что у серверов Akamai есть какой-то "прямой доступ" к тем дискам, на которых работают сервера MSDN?

Здравствуйте, gandjustas, Вы писали:
G>В описанном тобой сценарии рулит SQLite или SQLCE + ОРМ, который умеет генерить схему БД по классам (например EF). Ему не надо будет отдельного сервака, да еще и запросы быстрее работать будут (ибо индексы и все в памяти процесса).
Можно и вообще и без ORM, а хреначить всё JSON-ом в таблицу objects(guid id, varchar(max) data).
В отличие от монги, это впоследствии можно превратить в полноценную RDB путём постепенного прикручивания типизации.

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

G>Да и хрен с ним, все равно все в одной сети стоит.

Мы похоже по разному понимаем partition tolerance. Как то факт что все узлы стоят в одной сети защитит от отказа узла?

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

G>Ага, и ни ссылочной целостности, ни транзакционности.

Ничего не мешает обеспечивать и то и другое на уровне приложения.

G>Ну так не надо пользоваться слабыми СУБД.

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

G>Значит хреновый кеш. Или вы кешем называете что-то другое. Например результаты обработки данных, но их не в кеше хранить надо.
G>При использовании кеша единственное на что можно рассчитывать, что элемента в кеше НЕ будет. Если вы рассчитываете, что элемент в кеше будет, то вы неправильно делаете.

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

M>>Не "нулевая", а достаточная в контексте текущей задачи.
G>На самом деле она стремится к нулю при увеличении нагрузки. Потому что такая система не дает верхней границы потери данных при сбое.

Система дает гарантию вида "если что, вы потеряете данные за последние N минут". На практике этого достаточно даже для биллинга.

Здравствуйте, Miroff, Вы писали:
M>Мы похоже по разному понимаем partition tolerance. Как то факт что все узлы стоят в одной сети защитит от отказа узла?

Да, вы по-разному понимаете partition tolerance. Partition — это потеря сообщений между некотрыми узлами.
Отказ узла — это fault, и fault tolerance в RDBMS доведён практически до совершенства. Почитайте, к примеру, про SQL Azure .

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

S>Да, вы по-разному понимаете partition tolerance. Partition — это потеря сообщений между некотрыми узлами.

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

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

M>С точки зрения внешнего наблюдателя монопенисуально произошла потеря сообщений вследствие отказа узла или отказа сети.
Нет. С точки зрения внешнего наблюдателя нет риска того, что изменение было успешно записано в отказавший узел.
Partition — это как раз ситуация split brain, когда существуют альтернативные точки зрения на реальность.
Fault — это особый вид partition, и для него есть особые методы предотвращения или борьбы.

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

Поймите, тот же самый fault tolerance — это же не просто "пуленепробиваемость". Это способ построить из N компонентов с availability A систему с availability A' > A.
Приличному инженеру обсуждать вещи типа "нельзя создать всерастворяющую жидкость, ибо в каком сосуде вы собираетесь заканчивать реакцию" можно только в шутку, на вечеринке с дамами.

А на работе инженер должен обсуждать способы достижения заданных характеристик bandwidth, latency, availability из подручных материалов.
К сожалению, такие обсуждения — большая редкость. Авторы "фундаментальных трудов" позволяют себе вещи типа

For a distributed system to be continuously available, every request received
by a non-failing node in the system must result in a response. That is, any
algorithm used by the service must eventually terminate. In some ways
this is a weak definition of availability: it puts no bound on how long the
algorithm may run before terminating, and therefore allows unbounded computation.
On the other hand, when qualified by the need for partition tolerance,
this can be seen as a strong definition of availability: even when severe
network failures occur, every request must terminate.

Казалось бы, о чём тут можно дальше рассуждать?
Нет, высасывается из пальца целая статья, и волны рассуждений годами расходятся по всему интернету. При этом с неожиданными выводами, вроде противопоставления RDBMS и CAP-теоремы.
И везде происходит один и тот же идиотизм: все характеристики признаются "булевыми". Типа либо есть consistency, либо её нету. То есть нет даже попыток количественно измерить inconsistency, и сопоставить её с availability или другими характеристиками.
Казалось бы, это очевидно: в реальной жизни никто не готов пожертвовать полностью ни одной характеристикой. Ведь отсутствие availability в такой постановке означает, что систему можно вовсе не включать, а отсутствие consistency даёт нам разрешение отвечать '42' на любой запрос.
В жизни интересует что-то типа "дайте мне гарантиии длины простоя не более 10 минут и гарантии того, что запрошенные мной данные будут когерентны с задержкой не более 20 минут".
И вот тут можно бы начинать обсуждать, сколько нод и в какой конфигурации нужно подключить друг к другу так, чтобы получить эти характеристики.

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

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

G>>Да и хрен с ним, все равно все в одной сети стоит.

M>Мы похоже по разному понимаем partition tolerance. Как то факт что все узлы стоят в одной сети защитит от отказа узла?

Да, ты неправильно понимаешь. Partition — когда два сервера живые, доступные для клиентов, но связи между ними нет, они не могут определить этот факт. В локальной сети такое создать сложно.
Почитай доказательство CAP, там подробно расписано.

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

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

G>>Ага, и ни ссылочной целостности, ни транзакционности.
M>Ничего не мешает обеспечивать и то и другое на уровне приложения.
Конечно ничего не мешает, можно и свою субд изобрести. Только трудозатраты на изобретение транзакционности в 10-50 раз выше трудозатрат на прикладную логику.

G>>Ну так не надо пользоваться слабыми СУБД.
M>Когда у меня встает выбор потратить один и тот же бюждет на лицензии, внедрение и поддержку или на разработку, я выбираю потратить на разработку а остаток пропить.
И это неправильно. Потому что почти любая разработка еще и поддержки требует, поэтому экономически более эффективно закрыть потребность готовым продуктом, чем силами разработчиков.
Ну и за лицензии платит заказчик, а для него вложится в SQL гораздо выгоднее, чем отдать деньги хренпоймикому. Для разработчика SQL Server стоит $500.

G>>Значит хреновый кеш. Или вы кешем называете что-то другое. Например результаты обработки данных, но их не в кеше хранить надо.
G>>При использовании кеша единственное на что можно рассчитывать, что элемента в кеше НЕ будет. Если вы рассчитываете, что элемент в кеше будет, то вы неправильно делаете.
M>В реальной жизни если в кэше не будет ни одного элемента, система ляжет еще на старте.
В любом кеше будет момент когда в кеше не будет ни одного элемента, как же все работают?

M>Истории известно по крайней мере несколько случаев когда крупные кластера не могли подняться после сбоя по питанию.
Я тоже такое видел, крайне хреново были написаны такие системы. Парочку даже чинил.

M>>>Не "нулевая", а достаточная в контексте текущей задачи.
G>>На самом деле она стремится к нулю при увеличении нагрузки. Потому что такая система не дает верхней границы потери данных при сбое.
M>Система дает гарантию вида "если что, вы потеряете данные за последние N минут".
За N минут может пропасть сколько угодно данных.

M>На практике этого достаточно даже для биллинга.
Ага, вплоть до первой потери данных.

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

M>Кэши это 90% использований NoSQL. А дальше происходит логический переход: если приложение 99% времени работает только с кэшем, может вместо РСУБД взять персистентный кэш?

Персистентный кэш — это пять. Это как сухая вода.
Если 99% времени свинья работает с желудями, то следует логический переход — отказаться от дуба

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

DS> Персистентный кэш — это пять. Это как сухая вода.

Тем не менее довольно много архитектур построено на персистентных KV хранилищах используемых в качестве кэшей. Это единственный вменяемый способ обеспечить приемлемую скорость прогрева кэшей на больших объемах данных.

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

G>Конечно ничего не мешает, можно и свою субд изобрести. Только трудозатраты на изобретение транзакционности в 10-50 раз выше трудозатрат на прикладную логику.

Нет там никаких специальных затрат, создавай файл внутри транзакции БД и удаляй при откате транзакции.

G>И это неправильно. Потому что почти любая разработка еще и поддержки требует, поэтому экономически более эффективно закрыть потребность готовым продуктом, чем силами разработчиков.

Поддержка тоже пойдет в карман моей команды, а не консультантам из MS, и это правильно.

G>Ну и за лицензии платит заказчик, а для него вложится в SQL гораздо выгоднее, чем отдать деньги хренпоймикому. Для разработчика SQL Server стоит $500.

К счастью заказчика можно убедить потратить деньги не на лицензии, а на разработку того решения которое нужно именно ему.

G>В любом кеше будет момент когда в кеше не будет ни одного элемента, как же все работают?

Прогревают кэши перед запуском рабочей нагрузки.

G>За N минут может пропасть сколько угодно данных.

Мы же тут инженеры. Есть вполне определенный поток данных M сообщений в минуту, умножаем N * M и получаем не "сколько угодно", а конкретную цифру с нужными допусками.

G>Ага, вплоть до первой потери данных.

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

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

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

G>>Конечно ничего не мешает, можно и свою субд изобрести. Только трудозатраты на изобретение транзакционности в 10-50 раз выше трудозатрат на прикладную логику.

M>Нет там никаких специальных затрат, создавай файл внутри транзакции БД и удаляй при откате транзакции.

Ты не понимаешь масштаб проблемы. Самое сложное в транзакциях обеспечить атомарность и изолированность. Вот что будет если две транзакции одновременно попытаются создать файл с одинаковым именем.

G>>И это неправильно. Потому что почти любая разработка еще и поддержки требует, поэтому экономически более эффективно закрыть потребность готовым продуктом, чем силами разработчиков.

M>Поддержка тоже пойдет в карман моей команды, а не консультантам из MS, и это правильно.
Для заказчика выйдет дороже и с худшим качеством. В любом конкурсе посоны с SQL Server тебя отожмут.

G>>Ну и за лицензии платит заказчик, а для него вложится в SQL гораздо выгоднее, чем отдать деньги хренпоймикому. Для разработчика SQL Server стоит $500.

M>К счастью заказчика можно убедить потратить деньги не на лицензии, а на разработку того решения которое нужно именно ему.
Убедить можно ровно один раз.

G>>В любом кеше будет момент когда в кеше не будет ни одного элемента, как же все работают?
M>Прогревают кэши перед запуском рабочей нагрузки.

Очень плохо написана такая система.

G>>За N минут может пропасть сколько угодно данных.

M>Мы же тут инженеры. Есть вполне определенный поток данных M сообщений в минуту, умножаем N * M и получаем не "сколько угодно", а конкретную цифру с нужными допусками.
Да но если ты предполагаешь масштабирование, то M не ограничено заранее.

G>>Ага, вплоть до первой потери данных.

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

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

G>Ты не понимаешь масштаб проблемы. Самое сложное в транзакциях обеспечить атомарность и изолированность.

Атомарность и изолированность обеспечат транзакции БД.

G>Вот что будет если две транзакции одновременно попытаются создать файл с одинаковым именем.

При правильной низкоуровневой архитектуре невозможно создать два файла с одинаковым именем в одном месте.

G>Для заказчика выйдет дороже и с худшим качеством. В любом конкурсе посоны с SQL Server тебя отожмут.

Кто знает. С MS SQL тоже разные люди работают с разной ценой и разным качеством.

G>Убедить можно ровно один раз.

Спорно. Были заказчики которые слезли с елки Oracle и очень радовались по этому поводу.

G>Очень плохо написана такая система.

Предложи альтернативу с теми же характеристиками или лучшими на том же железе.

G>Да но если ты предполагаешь масштабирование, то M не ограничено заранее.

В значительных пределах можно подкручивать N чтобы гарантии оставались в допуске.

G>Восстановление по логам это ACID транзакции, которыми не обладают большая часть NoSQL решений.

Это делается руками на уровне приложения, независимо от использемого хранилища. Никакие ACID транзакции в твоем SQL Server тебя не спасут, например, от багов в application layer.

Здравствуйте, Miroff, Вы писали:
M>Тем не менее довольно много архитектур построено на персистентных KV хранилищах используемых в качестве кэшей. Это единственный вменяемый способ обеспечить приемлемую скорость прогрева кэшей на больших объемах данных.
Это скорее единственный вменяемый способ использовать KV-хранилище

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

M>Это делается руками на уровне приложения, независимо от использемого хранилища. Никакие ACID транзакции в твоем SQL Server тебя не спасут, например, от багов в application layer.
От багов в application layer спасают декларативные констреинты.
Вся вот эта сложная муть, которую так не любят тру носкл девелоперы — unique constraint, foreign key constraint, и прочие навороты — гарантируют, что виновное приложение упадёт с ODBC Error: "невнятное бла-бла-бла для лога", а не сжуёт ваш чудесный JSON в труху. А поддержка транзакций гарантирует то, что после этого падения БД вернёт данные в то состояние, которое имелось на момент begin tran, как будто виновное приложение никогда и не пыталось сделать delete from customer_accounts where 1=1.

Конечно, не всё можно повесить на декларативку. Конечно же есть способ сделать какую-то гадость. Но в SQL у меня как минимум есть хоть какие-то гарантии. А "обеспечивать их руками на уровне приложения" — спасибо, развеселили. Я помню, в 1998 году нашёл багу, допущенную в системе с "ручным обеспечением целостности" в 1997 году.
В общей сложности на восстановление разрушений, произошедших из-за этой баги, ушло порядка двух человекомесяцев — это когда операторы руками с бумажки забивают утраченные данные, а программисты потом натравливают на базу рукопашные скрипты для приведения ссылок в соответствие. Плюс ещё наверное от одного до трёх человекомесяцев было потрачено на попытки найти причину баги, и реализацию костылей, частично предотвращающих самое нехорошее. Полтора года бага блуждала по системе.

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

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

G>>Ты не понимаешь масштаб проблемы. Самое сложное в транзакциях обеспечить атомарность и изолированность.

M>Атомарность и изолированность обеспечат транзакции БД.
Речь шла о том, что используется KV хранилище и ФС для файлов. Так как атомарность обеспечить?

G>>Вот что будет если две транзакции одновременно попытаются создать файл с одинаковым именем.
M>При правильной низкоуровневой архитектуре невозможно создать два файла с одинаковым именем в одном месте.
Если использовать хорошие СУБД, то вся "низкоуровневая архитектура" уже реализована в них. В 99,999% задач писать такую архитектуру не нужно.

G>>Для заказчика выйдет дороже и с худшим качеством. В любом конкурсе посоны с SQL Server тебя отожмут.
M>Кто знает. С MS SQL тоже разные люди работают с разной ценой и разным качеством.
При прочих равных решение на промышленной СУБД для заказчика выгоднее, чем древнее KV+тонна кастом кода.

G>>Убедить можно ровно один раз.
M>Спорно. Были заказчики которые слезли с елки Oracle и очень радовались по этому поводу.
Oracle стоит как самолет (серьезно), MS SQL в порядок дешевле. Оракл по цене оправдан только в банковских процессингах.

G>>Очень плохо написана такая система.
M>Предложи альтернативу с теми же характеристиками или лучшими на том же железе.
Легко, дашь контакты лиц, принимающих решения?

G>>Да но если ты предполагаешь масштабирование, то M не ограничено заранее.
M>В значительных пределах можно подкручивать N чтобы гарантии оставались в допуске.
Если у тебя M и N заранее никак не ограничены, то и объем потерь не ограничен. Кроме того полностью исключить потери все равно не выйдет.

G>>Восстановление по логам это ACID транзакции, которыми не обладают большая часть NoSQL решений.
M>Это делается руками на уровне приложения, независимо от использемого хранилища.
Каким образом?
У тебя есть KV хранилище и ФС. И то и другое может в любой момент отказать, сервер приложений тоже может упасть в любой момент.
Приведи алгоритм, который гарантирует, что будут одновременно добавлены файл и запись в KV хранилище или не добавлены вовсе.

Сразу скажу, что теоретически задача решается только двухфазным коммитом и логом в надежном хранилище (запись на диск без буферизации). Но это уже сделано в СУБД, предложишь свое лепить?
Есть альетрнативный вариант — идемпотентные операции и повторы на клиенте. Но у нас клиент обычный браузер и заставлять его повторять действия непросто.

M>Никакие ACID транзакции в твоем SQL Server тебя не спасут, например, от багов в application layer.
От багов вообще ничего не спасет. Но если ты начнешь руками транзакции делать, то сделаешь тонну багов, которые со взрослой СУБД не появятся никогда.

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

S>От багов в application layer спасают декларативные констреинты.

Не от всех. Если приложение в какой-то ситуации с одного счета спишет средства, а не другой не добавит (не из-за исключения, а из-за ошибки в логике), никакие констрейнты на уровне хранилища тебя не спасут.

S>Конечно, не всё можно повесить на декларативку. Конечно же есть способ сделать какую-то гадость. Но в SQL у меня как минимум есть хоть какие-то гарантии. А "обеспечивать их руками на уровне приложения" — спасибо, развеселили. Я помню, в 1998 году нашёл багу, допущенную в системе с "ручным обеспечением целостности" в 1997 году.

Как бы с 1998 года 16 лет прошло, мир немного изменился.

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

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

S>>От багов в application layer спасают декларативные констреинты.

M>Не от всех. Если приложение в какой-то ситуации с одного счета спишет средства, а не другой не добавит (не из-за исключения, а из-за ошибки в логике), никакие констрейнты на уровне хранилища тебя не спасут.
От этого как раз спасают транзакции. Они не позволят снять с одного счета и не положить на другой. А констрейнты еще спасут от получения отрицательного баланса. Ни одна NoSQL база на сегодня такое делать не умеет.

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

G>Речь шла о том, что используется KV хранилище и ФС для файлов. Так как атомарность обеспечить?

Речь шла о FS vs. filetable.

G>Если использовать хорошие СУБД, то вся "низкоуровневая архитектура" уже реализована в них. В 99,999% задач писать такую архитектуру не нужно.

Если у тебя 99% задач не требует, это не значит что у всех так.

G>При прочих равных решение на промышленной СУБД для заказчика выгоднее, чем древнее KV+тонна кастом кода.

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

G>Oracle стоит как самолет (серьезно), MS SQL в порядок дешевле. Оракл по цене оправдан только в банковских процессингах.

К MS SQL прилагается весь стек MS что тоже не уменьшает стоимость решения.

G>Легко, дашь контакты лиц, принимающих решения?

Конечно не дам

G>Если у тебя M и N заранее никак не ограничены, то и объем потерь не ограничен. Кроме того полностью исключить потери все равно не выйдет.

N мы выбираем произвольно, M ограничен как минимум законами физики. Если у нас есть допустимая величина потерь, а в задаче с выбором баннера она есть, этой гарантии достаточно.

G>Каким образом?
G>Есть альетрнативный вариант — идемпотентные операции и повторы на клиенте. Но у нас клиент обычный браузер и заставлять его повторять действия непросто.

Что мешает приложению самому повторять действия?

G>От багов вообще ничего не спасет. Но если ты начнешь руками транзакции делать, то сделаешь тонну багов, которые со взрослой СУБД не появятся никогда.

От багов спасут проверки целостности на уровне приложения или на уровне мониторинга (классический пример — сходимость бухгалтерского баланса) и отработанные процедуры восстановления. У Синклера в соседней ветке проблема была не в том что целостность обеспечивалась руками (а как еще в 1997 году

) а в том что этот баг мерцал 1.5 года незамеченным и в том что операторы восстанавливали данные с бумажки, а не скрипты из логов.

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

G>От этого как раз спасают транзакции. Они не позволят снять с одного счета и не положить на другой. Ни одна NoSQL база на сегодня такое делать не умеет.

Каким образом они спасут?

BEGIN;
UPDATE accounts SET balance=balance - 100 WHERE id = 100500;
;А этот запрос не был отправлен из-за ошибки в коде
;UPDATE accounts SET balance=balance + 100 WHERE id = 100501;
COMMIT;

С точки зрения ACID все ок, а на практике бага и неконсистентность. Причем это могут быть счета разной размерности, списываем рубли, а добавляем мегабайты посчитанные по сложным правилам тарификации.

G>А констрейнты еще спасут от получения отрицательного баланса.

Отрицательный баланс это штатная ситуация, констрейнты не в тему К сожалению с констрейнтами это частая проблема, вроде при проектировании все ОК, а при разработке/эксплуатации выясняется что констрейнт слишком сильный или слишком слабый.

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

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

G>>От этого как раз спасают транзакции. Они не позволят снять с одного счета и не положить на другой. Ни одна NoSQL база на сегодня такое делать не умеет.

M>Каким образом они спасут?

M>

M>BEGIN;
M>UPDATE accounts SET balance=balance - 100 WHERE id = 100500;
M>;А этот запрос не был отправлен из-за ошибки в коде
M>;UPDATE accounts SET balance=balance + 100 WHERE id = 100501;
M>COMMIT;
M>

M>С точки зрения ACID все ок, а на практике бага и неконсистентность. Причем это могут быть счета разной размерности, списываем рубли, а добавляем мегабайты посчитанные по сложным правилам тарификации.
Приведи пример такого бага в коде. Как его вообще можно сделать ненамеренно?
Для учета движения бабла надо применять двойную бухгалтерскую запись.

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

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

G>>Речь шла о том, что используется KV хранилище и ФС для файлов. Так как атомарность обеспечить?

M>Речь шла о FS vs. filetable.
Ну предпложим что у нас есть БД c ACID и ФС. Нужно атомарно записать картинку вместе с метаданными.
1) Происходит запись строки в СУБД
2) Происходит запись файла на диск
3) Падает сервер приложений и не успевает отправить коммит.
Транзакция в СУБД откатывается, файл на диске остается.
В итоге из за такого решения появилась потребность писать фоновую задачу очистки файлового хранилища.

G>>Если использовать хорошие СУБД, то вся "низкоуровневая архитектура" уже реализована в них. В 99,999% задач писать такую архитектуру не нужно.
M>Если у тебя 99% задач не требует, это не значит что у всех так.
Это у всех так. Очень мало компаний, которым реально не достаточно возможностей взрослых СУБД. А для тех кому взрослых СУБД много — подойдут embedded базы.

G>>При прочих равных решение на промышленной СУБД для заказчика выгоднее, чем древнее KV+тонна кастом кода.
M>Зависит от конкретного проекта. Где-то дешевле одно, где-то другое. Для заказчика может быть выгоднее каждый месяц платить понемногу, чем сразу бухнуть мешок денег в лицензии.
А ты думаешь с лицензиями на SQL Server\Oracle нельзя "платить по немногу" ? Причем это "немного" оказывается меньше стоимости одного разработчика.

G>>Oracle стоит как самолет (серьезно), MS SQL в порядок дешевле. Оракл по цене оправдан только в банковских процессингах.
M>К MS SQL прилагается весь стек MS что тоже не уменьшает стоимость решения.
Весь стек это что? Windows Server? Ты думаешь что те, кто покупают Oracle пользуются бесплатными линуксами?

G>>Если у тебя M и N заранее никак не ограничены, то и объем потерь не ограничен. Кроме того полностью исключить потери все равно не выйдет.
M>N мы выбираем произвольно, M ограничен как минимум законами физики. Если у нас есть допустимая величина потерь, а в задаче с выбором баннера она есть, этой гарантии достаточно.
Да нету никакой гарантии, игры с цифрами не помогут, заранее спрогнозировать потери не получится. Понятно что в реальности больше некоторого объема не потеряешь, но потеря даже одной записи это слишком много, особенно если не случилось никакой катастрофы.

G>>Каким образом?
G>>Есть альетрнативный вариант — идемпотентные операции и повторы на клиенте. Но у нас клиент обычный браузер и заставлять его повторять действия непросто.

M>Что мешает приложению самому повторять действия?
Оно тоже падает и не знает какие запросы пришл к нему до того как приложение упало. Причем именно приложение падает или перезапускается чаще других.

G>>От багов вообще ничего не спасет. Но если ты начнешь руками транзакции делать, то сделаешь тонну багов, которые со взрослой СУБД не появятся никогда.

M>От багов спасут проверки целостности на уровне приложения
Ты о чем? Как они спасут, если нет гарантии атомарности записи?
Предположим ты можешь на уровне приложения гарантировать, что деньги снятые с одного счета всегда попадут на второй. Но у тебя хранилище без гарантий и одну операцию успеет записать, а вторую нет.
итоге твои гарантии ничего не стоят.

M>или на уровне мониторинга (классический пример — сходимость бухгалтерского баланса) и отработанные процедуры восстановления.

Вот в конце квартала конце месяца появляется надпись "баланс не сходится" и что делать?

ACID позволяет сделать сходящийся баланс в любой момент времени и за любой период без дополнительного кода. А ты предлагаешь "отработанные процедуры восстановления"?

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

M> У Синклера в соседней ветке проблема была не в том что целостность обеспечивалась руками (а как еще в 1997 году

) а в том что этот баг мерцал 1.5 года незамеченным и в том что операторы восстанавливали данные с бумажки, а не скрипты из логов.

Проблема в том, что ACID гарантии привычны для человека. А тут получилась система, которая делала вид, что давала ACID гарантии, а по факту не всегда. Естественно никто не стал писать дополнительно проверочный код, потому что программисты типа тебя уверяли что контроль делается на уровне приложения. В итоге накопилась значительная ошибка и пришлось по бумажкам сверять.

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

M>Когда у меня встает выбор потратить один и тот же бюждет на лицензии, внедрение и поддержку или на разработку, я выбираю потратить на разработку а остаток пропить.

а потом заказчики понимают, что связались с "варварами" и кусают локти, что ничего нормально не работает

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

M>От багов спасут проверки целостности на уровне приложения или на уровне мониторинга (классический пример — сходимость бухгалтерского баланса) и отработанные процедуры восстановления. У Синклера в соседней ветке проблема была не в том что целостность обеспечивалась руками (а как еще в 1997 году

) а в том что этот баг мерцал 1.5 года незамеченным и в том что операторы восстанавливали данные с бумажки, а не скрипты из логов.
Чисто объяснить: баг был прекрасно замечен. Просто не могли найти, где именно он скрыт. Оказалось, было редкое стечение обстоятельств, когда код декремента рефкаунта считал данные указателем, а код инкремента — интом.
Целостность в 1997 году можно было обеспечить и базой — просто мы выбрали конкретную схему маппинга объектов на таблицы, при которой не удавалось реализовать концепцию foreign key на уровне базы. По крайней мере нам, с нашей тогдашней квалификацией. На всякий случай поясню: в те времена промышленных ORM не существовало, а Фаулер только собирался написать свои фундаментальные труды.

Это всего лишь иллюстрация того, что рукопашные решения таких низкоуровневых задач — это не то удовольствие, которое можно себе позволить. Одна такая бага — и стоимость лицензии на MS SQL можно считать отбитой.

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

M>

M>BEGIN;
M>UPDATE accounts SET balance=balance - 100 WHERE id = 100500;
M>;А этот запрос не был отправлен из-за ошибки в коде
M>;UPDATE accounts SET balance=balance + 100 WHERE id = 100501;
M>COMMIT;
M>

Теоретически даже это можно обложить констреинтами — сумма всех денег в системе должна быть = 0.
А если не 0 — откат и начинаем сначала. На практике ситуация такого типа отлавливается тестами, зато ситуация когда у нас код не закомментирован, а просто падает из-за баги прекрасно хэндлится. Это резко сокращает требуемый объём тестирования.

M>Отрицательный баланс это штатная ситуация, констрейнты не в тему К сожалению с констрейнтами это частая проблема, вроде при проектировании все ОК, а при разработке/эксплуатации выясняется что констрейнт слишком сильный или слишком слабый.
Именно поэтому разработчики RDBMS не сидят на попе ровно последние 30 лет, а пилят и строгают. Современная RDBMS — это далеко не только not null constraint. Там тебе и semantic query optimization, и predictive io, и ещё много чего.

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

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

DS>> Персистентный кэш — это пять. Это как сухая вода.

M>Тем не менее довольно много архитектур построено на персистентных KV хранилищах используемых в качестве кэшей.

Может этот термин и употребляется, но по сути "персистентный кэш" — оксюморон.

... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>

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

G>В итоге из за такого решения появилась потребность писать фоновую задачу очистки файлового хранилища.

Эту потребность можно отложить лет на 15. Функциональность системы от такой неконсистентности не пострадает.

G>Это у всех так. Очень мало компаний, которым реально не достаточно возможностей взрослых СУБД. А для тех кому взрослых СУБД много — подойдут embedded базы.

Можешь считать так, но рост популярности noSQL решений говорит об обратном.

G>А ты думаешь с лицензиями на SQL Server\Oracle нельзя "платить по немногу" ? Причем это "немного" оказывается меньше стоимости одного разработчика.

Нельзя. Надо сразу отсыпать кучу денег на хорошее железо, ОС, СУБД и инструменты разработчика. При этом когда производительности такого решения перестанет хватать придется потратить еще кучу денег на консультантов, которые скажут: "Смотрите планы запросов и добавляйте индексы. Не помогло? Тогда купите сервер вдвое больше и не забудьте обновить лицензии"

G>Весь стек это что? Windows Server? Ты думаешь что те, кто покупают Oracle пользуются бесплатными линуксами?

Представь себе, пользуются.

G>Да нету никакой гарантии, игры с цифрами не помогут, заранее спрогнозировать потери не получится. Понятно что в реальности больше некоторого объема не потеряешь, но потеря даже одной записи это слишком много, особенно если не случилось никакой катастрофы.

Ну если арифметика тебе не подвластна, сожалею.

G>Оно тоже падает и не знает какие запросы пришл к нему до того как приложение упало. Причем именно приложение падает или перезапускается чаще других.

Идемпотентные же операции. Тупо повторить все за последние 5 минут.

G>Ты о чем? Как они спасут, если нет гарантии атомарности записи?

Куда бы она делась? Большинство noSQL решений гарантируют ACID в пределах одной записи.

G>Вот в конце квартала конце месяца появляется надпись "баланс не сходится" и что делать?

Инвестигейтить и фиксить, что же еще.

G>ACID позволяет сделать сходящийся баланс в любой момент времени и за любой период без дополнительного кода. А ты предлагаешь "отработанные процедуры восстановления"?

Нет не позволяет, потому что инварианты уровня приложения не выражаются в терминах констрейнтов хранилища данных. Если ты попытаешь их туда упихать, то половина логики приложения будет продублирована в хранимых процедурах. Тоже подход, но от него даже в мире взрослых СУБД повсеместно отказались.

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

G>Приведи пример такого бага в коде. Как его вообще можно сделать ненамеренно?

Мы тут обсуждаем все же хранилища данных, а не код. Любой баг который технически можно допустить в коде, рано или поздно будет допущен.

G>Для учета движения бабла надо применять двойную бухгалтерскую запись.

А если с одной стороны бабло, а с другой кВт/ч?

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

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

G>>В итоге из за такого решения появилась потребность писать фоновую задачу очистки файлового хранилища.
M>Эту потребность можно отложить лет на 15. Функциональность системы от такой неконсистентности не пострадает.
Слишком самоуверенно.

G>>Это у всех так. Очень мало компаний, которым реально не достаточно возможностей взрослых СУБД. А для тех кому взрослых СУБД много — подойдут embedded базы.
M>Можешь считать так, но рост популярности noSQL решений говорит об обратном.
Что такое рост популярности? Я вот видел несколько живых применений NoSQL, во всех случаях это было не основное хранилище и везде признано ошибочным решением.

G>>А ты думаешь с лицензиями на SQL Server\Oracle нельзя "платить по немногу" ? Причем это "немного" оказывается меньше стоимости одного разработчика.

M>Нельзя. Надо сразу отсыпать кучу денег на хорошее железо, ОС, СУБД и инструменты разработчика. При этом когда производительности такого решения перестанет хватать придется потратить еще кучу денег на консультантов, которые скажут: "Смотрите планы запросов и добавляйте индексы. Не помогло? Тогда купите сервер вдвое больше и не забудьте обновить лицензии"
А NoSQL на святом духе работает? Ты забыл что NoSQL базы обычно требуют больше железа, чем SQL при той же нагрузке и объеме данных?

G>>Весь стек это что? Windows Server? Ты думаешь что те, кто покупают Oracle пользуются бесплатными линуксами?
M>Представь себе, пользуются.
Не верю, примеры в студию.

G>>Да нету никакой гарантии, игры с цифрами не помогут, заранее спрогнозировать потери не получится. Понятно что в реальности больше некоторого объема не потеряешь, но потеря даже одной записи это слишком много, особенно если не случилось никакой катастрофы.
M>Ну если арифметика тебе не подвластна, сожалею.
Ты не понимаешь разницу между вероятностью и гарантией

G>>Оно тоже падает и не знает какие запросы пришл к нему до того как приложение упало. Причем именно приложение падает или перезапускается чаще других.
M>Идемпотентные же операции. Тупо повторить все за последние 5 минут.
А кто хранит список всех операций за последние 5 минут?

G>>Ты о чем? Как они спасут, если нет гарантии атомарности записи?
M>Куда бы она делась? Большинство noSQL решений гарантируют ACID в пределах одной записи.
Увы, такой гарантии для большинства сценариев недостаточно.

G>>Вот в конце квартала конце месяца появляется надпись "баланс не сходится" и что делать?
M>Инвестигейтить и фиксить, что же еще.

G>>ACID позволяет сделать сходящийся баланс в любой момент времени и за любой период без дополнительного кода. А ты предлагаешь "отработанные процедуры восстановления"?
M>Нет не позволяет, потому что инварианты уровня приложения не выражаются в терминах констрейнтов хранилища данных.
С чего ты взял? Выражается все. Причем в случае учетной системы очень просто.

M>Если ты попытаешь их туда упихать, то половина логики приложения будет продублирована в хранимых процедурах. Тоже подход, но от него даже в мире взрослых СУБД повсеместно отказались.
При чем ту хранимые процедуры? Ты про constraint в курсе?

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

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

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

G>>Для учета движения бабла надо применять двойную бухгалтерскую запись.
M>А если с одной стороны бабло, а с другой кВт/ч?
А в чем проблема?

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

G>Что такое рост популярности? Я вот видел несколько живых применений NoSQL, во всех случаях это было не основное хранилище и везде признано ошибочным решением.

Рост количества использований в новых проектах. Проверяется элементарным анализом рынка труда.

G>А NoSQL на святом духе работает? Ты забыл что NoSQL базы обычно требуют больше железа, чем SQL при той же нагрузке и объеме данных?

Почему-то это так только когда железо начинают считать адепты SQL.

G>Не верю, примеры в студию.

Тот заказчик который радовался слезанию с оракла как раз сидел на красной шапке.

G>Ты не понимаешь разницу между вероятностью и гарантией

А ты не понимаешь разницу между вероятностью и оценкой сверху

G>А кто хранит список всех операций за последние 5 минут?

Приложение же и хранит, на диске в rolled logs. Записали в журнал, ответили клиенту "ОК" и начали процессить.

G>Увы, такой гарантии для большинства сценариев недостаточно.

Это вопрос точки зрения. Для моих задач достаточно, для твоих не достаточно.

G>С чего ты взял? Выражается все. Причем в случае учетной системы очень просто.
G>При чем ту хранимые процедуры? Ты про constraint в курсе?

Ок, вот тебе бизнес-требование:

Пользователь может списывать со счета средства и покупать попугаев по предоплате согласно тарифному плану. Тарифный план:
До 10 попугаев за последний месяц: 1 попугай — 100 рублей
Больше 10 попугаев за последний месяц: 1 попугай — 50 рублей

Попугаи пользователя расходуются в рабочем порядке. В случае отсутствия попугая на счету пользователя, попугай выдается пользователю в кредит с одновременным снятием со счета пользователя суммы согласно тарифному плану. Отрицательный остаток на счете пользователя допустим.

Изобрази, пожалуйста двойную бухгалтерскую запись и констрейнты на ней.

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

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

G>>Что такое рост популярности? Я вот видел несколько живых применений NoSQL, во всех случаях это было не основное хранилище и везде признано ошибочным решением.

M>Рост количества использований в новых проектах. Проверяется элементарным анализом рынка труда.
Уже спад наблюдается, рост был года два назад.

G>>А NoSQL на святом духе работает? Ты забыл что NoSQL базы обычно требуют больше железа, чем SQL при той же нагрузке и объеме данных?
M>Почему-то это так только когда железо начинают считать адепты SQL.
Вполне реальный случай. Жила была система, на одном сервере SQL. Железо — 32 гб памяти и 12 ядер.
Решили соптимизировать поставив MongoDB и сделав на ней "очередь". Когда я крайний раз видел монга была на 4 серверах по 8гб и 4 ядра и собирались ставить еще два.
Можно было кстати оптимизировать SQL, тогда он бы отдыхал все время.

G>>Ты не понимаешь разницу между вероятностью и гарантией

M>А ты не понимаешь разницу между вероятностью и оценкой сверху

Так ты же вероятность оцениваешь, предполагая что запросы распределены равномерно.

G>>А кто хранит список всех операций за последние 5 минут?
M>Приложение же и хранит, на диске в rolled logs. Записали в журнал, ответили клиенту "ОК" и начали процессить.
Все РСУБД и так это делают

Даже некоторые nosql тоже так делают.
А свое писать крайне сложно.
Представь что у тебя два сервера и такая последовательность:
1) На первый приходит команда увеличить А на единицу
2) На второй приходит команда увеличить А в два раза
3) Первый сервер падает
4) второй процессит изменения, в storage попадает A*2
5) Первый сервер просыпается, процессит изменения, в storage попадает A*2+1
А результатом операции должно было быть (A+1)*2.

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

G>>Увы, такой гарантии для большинства сценариев недостаточно.
M>Это вопрос точки зрения. Для моих задач достаточно, для твоих не достаточно.
Тогда не точки зрения, а сценария. Допускаю что ты пишешь что-то простое и тебе это все не нужно.
Но:
1) завтра ситуация может измениться
2) даже в простом сценарии у nosql нет преимуществ

G>>С чего ты взял? Выражается все. Причем в случае учетной системы очень просто.
G>>При чем ту хранимые процедуры? Ты про constraint в курсе?

M>Ок, вот тебе бизнес-требование:

M>

M>Пользователь может списывать со счета средства и покупать попугаев по предоплате согласно тарифному плану. Тарифный план:
M>До 10 попугаев за последний месяц: 1 попугай — 100 рублей
M>Больше 10 попугаев за последний месяц: 1 попугай — 50 рублей

M>Попугаи пользователя расходуются в рабочем порядке. В случае отсутствия попугая на счету пользователя, попугай выдается пользователю в кредит с одновременным снятием со счета пользователя суммы согласно тарифному плану. Отрицательный остаток на счете пользователя допустим.

Вообще-то речь шла о сходящемся балансе в любой момент времени. Тарифные планы тут не при чем.

M>Изобрази, пожалуйста двойную бухгалтерскую запись и констрейнты на ней.
Специально для тебя:
1) Таблица проводок (id, дата, кредит, дебет, сумма, попугаи)
2) Функция Количество попугаев за месяц по пользователю — простой select по таблице проводок
3) CHECK CONSTRAINT на таблице проводок, который вызывает функцию из 2), вычисляет стоимость одного попугая и сравнивает с заданной

Но еще лучше прямо в insert считать, тогда бизнес правила не будут прибиты к к схеме данных.

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

M>Ок, вот тебе бизнес-требование:

M>

M> Пользователь может списывать со счета средства и покупать попугаев по предоплате согласно тарифному плану. Тарифный план:
M>До 10 попугаев за последний месяц: 1 попугай — 100 рублей
M>Больше 10 попугаев за последний месяц: 1 попугай — 50 рублей

M>Попугаи пользователя расходуются в рабочем порядке. В случае отсутствия попугая на счету пользователя , попугай выдается пользователю в кредит с одновременным снятием со счета пользователя суммы согласно тарифному плану. Отрицательный остаток на счете пользователя допустим.

Это bullshit, а не бизнес требования. На счету средства, а попугаи — это купленный товар/услуга. Как попугай может оказаться на счету пользователя?

То же самое с деньги vs кВт из твоего какого-то предыдущего сообщения. Деньги — это счета, проводки, баланс; киловатты — оказанные услуги.

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

M>А если с одной стороны бабло, а с другой кВт/ч?
То будет ODBC Error: no implicit conversion exists. Затем rollback и см. п.1.

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

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

M>>А если с одной стороны бабло, а с другой кВт/ч?
S>То будет ODBC Error: no implicit conversion exists. Затем rollback и см. п.1.

Помоему Miroff просто не понимает, что для учета все величины переводится в инвариантные в момент формирования запроса.

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

M>Мы тут обсуждаем все же хранилища данных, а не код. Любой баг который технически можно допустить в коде, рано или поздно будет допущен.
Вы не понимаете простую вещь. RDBMS не ставят своей целью предотвратить вообще все баги. Но они дают приложениям механизм восстановления после сбоев.
Мне не надо изобретать хитромудрые стратегии пересчёта всего подряд и восстановления консистентности on demand. Если моё приложение напоролось на что-то неожиданное, ему достаточно выкинуть исключение. Неважно какое. Важно, что в результате этого исключения всё, что было поменяно к этому моменту, гарантированно откатится назад.
Логика между съёмом денег с одного счёта и их положением на другой может быть сколь угодно сложной. Там может сумма делиться на несколько счетов. Главное — что приложение, обнаружив неконсистентость чего угодно — хоть неправильность почтового адреса для отправки подтверждения — может просто сказать "адью", и не думать о том, как вернуть всё обратно. Платформа гарантирует, что обратно вернётся всё.
А ведь "баги в логике" — это редкий зверь. Именно логику тестируют в первую очередь. Большинство багов — это unexpected error. Null Reference Exception; Object Disposed Exception; Division by Zero и прочие чудеса. Т.е. написать такой баг, чтобы система успешно завершила транзакцию, но с неправильным результатом — это надо сильно постараться.

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

P>Это bullshit, а не бизнес требования. На счету средства, а попугаи — это купленный товар/услуга. Как попугай может оказаться на счету пользователя?
P>То же самое с деньги vs кВт из твоего какого-то предыдущего сообщения. Деньги — это счета, проводки, баланс; киловатты — оказанные услуги.

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

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

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

M>>А если с одной стороны бабло, а с другой кВт/ч?
S>То будет ODBC Error: no implicit conversion exists. Затем rollback и см. п.1.

Это в какой такой СУБД система типос настолько продвинута что отличает рубли от кВт/ч?

Здравствуйте, Miroff, Вы писали:
M>Это в какой такой СУБД система типос настолько продвинута что отличает рубли от кВт/ч?
В более-менее любой.
Читать, например, http://msdn.microsoft.com/en-us/library/ms175007(v=sql.90).aspx

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

G>Вполне реальный случай. Жила была система, на одном сервере SQL. Железо — 32 гб памяти и 12 ядер.
G>Решили соптимизировать поставив MongoDB и сделав на ней "очередь". Когда я крайний раз видел монга была на 4 серверах по 8гб и 4 ядра и собирались ставить еще два.
G>Можно было кстати оптимизировать SQL, тогда он бы отдыхал все время.

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

G>Так ты же вероятность оцениваешь, предполагая что запросы распределены равномерно.

Я могу с тем же успехом оценивать распределение и утверждать что с вероятность 99.9% запросов будет меньше N в секунду.

G>Представь что у тебя два сервера и такая последовательность:
G>Из-за подобных проблем синхронизации будет огромное количество багов.

Ты же сам начал с идемпотентных команд, а теперь уходишь куда-то не туда.

G>1) завтра ситуация может измениться

Когда нормальный разработчик анализирует требования он в том числе учитывает возможность изменения ситуации. Так что нет, настолько ситуация измениться не может.

G>2) даже в простом сценарии у nosql нет преимуществ

Цена и распределение бюджета в пользу команды это достаточное преимущество.

G>1) Таблица проводок (id, дата, кредит, дебет, сумма, попугаи)
G>2) Функция Количество попугаев за месяц по пользователю — простой select по таблице проводок
G>3) CHECK CONSTRAINT на таблице проводок, который вызывает функцию из 2), вычисляет стоимость одного попугая и сравнивает с заданной

QED: логика переехала из приложения в базу.

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

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

G>>Вполне реальный случай. Жила была система, на одном сервере SQL. Железо — 32 гб памяти и 12 ядер.
G>>Решили соптимизировать поставив MongoDB и сделав на ней "очередь". Когда я крайний раз видел монга была на 4 серверах по 8гб и 4 ядра и собирались ставить еще два.
G>>Можно было кстати оптимизировать SQL, тогда он бы отдыхал все время.

M>Т.е. на основании одной истории ты делаешь глобальные выводы?
У меня много таких историй, это просто последняя.

M>Знаю одну команду которая использует кластер Redis работающий на серверах позапрошлого поколения которые обходятся практически по цене электричества. Если заменить все это железно на одну железку она, во-первых, будет стоить несколько десятков килобаксов, а во-вторых, будет значительно менее надежна.
Редис это кеш, примерно как memcached. Я вообще не знаю кто его persistance использует.
MongoDB это хранилище, которое должно не терять данные, а объем данных растет все время.
Так что не очень корректно сравнивать.

G>>Так ты же вероятность оцениваешь, предполагая что запросы распределены равномерно.
M>Я могу с тем же успехом оценивать распределение и утверждать что с вероятность 99.9% запросов будет меньше N в секунду.
То есть будет 0,1% времени, когда запросов в секунду будет больше N и в случае падения в этот момент потеря данных будет больше.
Это значит все твои игры в теорию вероятностей гарантий не дают.

G>>Представь что у тебя два сервера и такая последовательность:
G>>Из-за подобных проблем синхронизации будет огромное количество багов.
M>Ты же сам начал с идемпотентных команд, а теперь уходишь куда-то не туда.
Да, я говорил что эти команды должен повторить клиент, а не сервер. В случае конфликтов клиент получил ошибку и разберется что с ней делать. А на сервере нет логики клиента, получив ошибку он не может сделать ничего.

G>>1) завтра ситуация может измениться
M>Когда нормальный разработчик анализирует требования он в том числе учитывает возможность изменения ситуации. Так что нет, настолько ситуация измениться не может.

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

G>>2) даже в простом сценарии у nosql нет преимуществ
M>Цена и распределение бюджета в пользу команды это достаточное преимущество.
С каких пор это преимущество?
Это не принесет дополнительной прибыли бизнесу.
Это принесет бизнесу дополнительные обязательства по поддержке.
Это не принесет преимуществ клиенту.
Это принесет клиенту дополнительные проблемы по поддержке.

Фактически nosql в такой ситуации это риск, который ложится на обе стороны. Внятных преимуществ вообще нет.

G>>1) Таблица проводок (id, дата, кредит, дебет, сумма, попугаи)
G>>2) Функция Количество попугаев за месяц по пользователю — простой select по таблице проводок
G>>3) CHECK CONSTRAINT на таблице проводок, который вызывает функцию из 2), вычисляет стоимость одного попугая и сравнивает с заданной

M>QED: логика переехала из приложения в базу.
Ты ловко выкинул мою последнюю фразу. Специально для тебя повторю:

Но еще лучше прямо в insert считать, тогда бизнес правила не будут прибиты к к схеме данных.

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

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

G>Редис это кеш, примерно как memcached. Я вообще не знаю кто его persistance использует.

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

G>MongoDB это хранилище, которое должно не терять данные, а объем данных растет все время.
G>Так что не очень корректно сравнивать.

Почему не очень корректно? Что мешает развернуть memcached на таком же кластере?

G>Это значит все твои игры в теорию вероятностей гарантий не дают.

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

G>Да, я говорил что эти команды должен повторить клиент, а не сервер. В случае конфликтов клиент получил ошибку и разберется что с ней делать. А на сервере нет логики клиента, получив ошибку он не может сделать ничего.

С идемпотентными командами не важно кто их повторяет, клиент или сервер. Никакая специальная логика для этого не нужна.

G>У меня есть более десятка примеров когда через месяц ситуация менялась после этих слов.

А у меня нет таких примеров. Там где ситуация менялась, это было 100% из-за того разработчик профакапил, хотя сами изменения были очевидны.

G>Фактически nosql в такой ситуации это риск, который ложится на обе стороны. Внятных преимуществ вообще нет.

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

Какой в итоге будет разница и в чью она будет пользу зависит от конкретного проекта.

M>>QED: логика переехала из приложения в базу.
G>Ты ловко выкинул мою последнюю фразу. Специально для тебя повторю:
G>

G>Но еще лучше прямо в insert считать, тогда бизнес правила не будут прибиты к к схеме данных.

Ты предергиваешь. Два поста назад мы говорили про констрейнты, "прямо в insert считать" к констрейнтам не относится.

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

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

G>>Редис это кеш, примерно как memcached. Я вообще не знаю кто его persistance использует.

M>Это не кэш, а KV хранилище которое можно использовать в качестве кэша, но можно и для других нужд. Redis часто используют для всяких счетчиков, от количества просмотров страницы, до лайков на посте. С одной стороны это не самые критичные данные чтобы пихать их в реляционку, с другой потерять их при перезагрузке сервера очень не хочется.
GA\Yandex.metrika не модно нынче? Зачем redis?
Если отбросить вырожденные случаи, то получается только кеш.

G>>MongoDB это хранилище, которое должно не терять данные, а объем данных растет все время.
G>>Так что не очень корректно сравнивать.
M>Почему не очень корректно? Что мешает развернуть memcached на таком же кластере?
Потому что монга данные хранит, а объем хранимых данных постоянно растет. А в кеше данные не растут, поэтому кеш всегда влезает в память, а хранимые данные — нет.
Это разные сценарии, разные требования по надежности, согласованности, изолированности итп.

G>>Это значит все твои игры в теорию вероятностей гарантий не дают.

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

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

G>>Да, я говорил что эти команды должен повторить клиент, а не сервер. В случае конфликтов клиент получил ошибку и разберется что с ней делать. А на сервере нет логики клиента, получив ошибку он не может сделать ничего.
M>С идемпотентными командами не важно кто их повторяет, клиент или сервер. Никакая специальная логика для этого не нужна.
Важно, потому что идемпотентные команды для клиента могут быть вовсе не таковыми для сервера. Да и не получится (очень сложно) все сделать только на идемпотентных командах.

G>>У меня есть более десятка примеров когда через месяц ситуация менялась после этих слов.
M>А у меня нет таких примеров. Там где ситуация менялась, это было 100% из-за того разработчик профакапил, хотя сами изменения были очевидны.

G>>Фактически nosql в такой ситуации это риск, который ложится на обе стороны. Внятных преимуществ вообще нет.

M>noSQL уменьшает издержки бизнеса за счет сокращения лицензионных платежей и за счет сокращения затрат на железо (три сервера прошлого поколения стоят дешевле одного современного).
Сокращения затрат на железо — не факт (ты даже примера не привел), вполне возможна обратная ситуация. Сокращение лицензионных отчислений будет меньше увеличения затрат на разработку.
Так что тут нет преимуществЮ есть только риск.

M>noSQL уменьшает риски столкнуться с проблемами масштабирования (У вас тут нагрузка выросла в два раза, извольте купить сервер помощнее. Насколько помощнее? Ну вас виднее на сколько у вас денег хватит)
Это вообще чушь. Мастшабирование SQL Server делается прекрасно путем добавления дисков, памяти, процессоров (во что уперлось, то и добавляем). А для масштабирования nosql хранилищ надо ставить новые серверы, при этом снижается надежность хранения.
При этом SQL Server прекрасно масштабируется по объему данных просто доставлением дисков и, иногда, памяти. И то и другое относительно дешево.
А для nosql в этом случае надо целые серваки покупать. Что на порядок дороже.

M>noSQL увеличивает стоимость разработки и сопровождения, но эти деньги идут в бюджет команды разработчиков и админов
Офигенное преимущество для заказчика

M>Какой в итоге будет разница и в чью она будет пользу зависит от конкретного проекта.
100% ты не продашь такое, если заказчик хоть сколько-нибудь грамотный.
Лучшее что ты можешь сделать — продать свою поделку как черный ящик, чтобы заказчик не знал что под капотом.

Ты выдаешь желаемое за действиетельное.

M>>>QED: логика переехала из приложения в базу.
G>>Ты ловко выкинул мою последнюю фразу. Специально для тебя повторю:
G>>

G>>Но еще лучше прямо в insert считать, тогда бизнес правила не будут прибиты к к схеме данных.

M>Ты предергиваешь. Два поста назад мы говорили про констрейнты, "прямо в insert считать" к констрейнтам не относится.
Про констрейнты я говорил в ответ на твое утверждение что в базе нельзя контролировать.

Ты пытаешься использовать классический прием демагогии. Задать два похожих вопроса, а потом делать вид что ответ на первый, также отвечает на второй наоборот.

Объясняю тебе еще раз:
1) если ты не доверяешь клиенту СУБД, то делаешь констрейнты в базе
2) если БД и клиент к ней делает один человек, то проще генерить запросы на клиенте.

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

G>GA\Yandex.metrika не модно нынче? Зачем redis?

GA/YM не всегда отвечают требованиям бизнеса. Опять же, зачем строчку про лайки выкинул? Это же не кэш.

G>Потому что монга данные хранит, а объем хранимых данных постоянно растет. А в кеше данные не растут, поэтому кеш всегда влезает в память, а хранимые данные — нет.
G>Это разные сценарии, разные требования по надежности, согласованности, изолированности итп.

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

G>Это твои фантазии. В СУБД есть гарантии, что после завершения коммита данные не потеряются.

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

G>Важно, потому что идемпотентные команды для клиента могут быть вовсе не таковыми для сервера. Да и не получится (очень сложно) все сделать только на идемпотентных командах.

Приведи, пожалуйста, пример команды которая одновременно идемпотентна и неидемпотентна.

G>Сокращения затрат на железо — не факт (ты даже примера не привел), вполне возможна обратная ситуация. Сокращение лицензионных отчислений будет меньше увеличения затрат на разработку.
G>Так что тут нет преимуществЮ есть только риск.

А ты когда-нибудь сам считал ТЭО для какого-нибудь проекта? Мне вот почему-то кажется что нет.

G>Это вообще чушь. Мастшабирование SQL Server делается прекрасно путем добавления дисков, памяти, процессоров (во что уперлось, то и добавляем). А для масштабирования nosql хранилищ надо ставить новые серверы, при этом снижается надежность хранения.

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

G>При этом SQL Server прекрасно масштабируется по объему данных просто доставлением дисков и, иногда, памяти. И то и другое относительно дешево.
G>А для nosql в этом случае надо целые серваки покупать. Что на порядок дороже.

Если покупать топовые сервера то дороже, а если ширпотребные десктопные железяки то дешевле.

G>100% ты не продашь такое, если заказчик хоть сколько-нибудь грамотный.

Т.е. в тех твоих многих историях про миграцию с MS SQL на noSQL все заказчики были неграмотные?

G>Про констрейнты я говорил в ответ на твое утверждение что в базе нельзя контролировать.
G>Ты пытаешься использовать классический прием демагогии. Задать два похожих вопроса, а потом делать вид что ответ на первый, также отвечает на второй наоборот.

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

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

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

G>>GA\Yandex.metrika не модно нынче? Зачем redis?
M>GA/YM не всегда отвечают требованиям бизнеса.
Например?

M>Опять же, зачем строчку про лайки выкинул? Это же не кэш.
Лайки можно и в sql хранить.

G>>Потому что монга данные хранит, а объем хранимых данных постоянно растет. А в кеше данные не растут, поэтому кеш всегда влезает в память, а хранимые данные — нет.
G>>Это разные сценарии, разные требования по надежности, согласованности, изолированности итп.
M>Предположим это так. И что? Для растущих данных можно добавлять ноды в кластер. Данные ведь ни сами по себе растут, с ними еще и количество пользователей растет.
Это неверно. Вот есть бухгалтерия в которой три человека работают, они за год генерируют несколько десятков ГБ только проводок. А про документы молчу.
Вообще в корпоративной среде количество пользователей всегда ограничено сверху, а объем данных — нет. А в публичных сайтах бывает ровно наоборот.

G>>Это твои фантазии. В СУБД есть гарантии, что после завершения коммита данные не потеряются.
M>В твоем определении гарантии, ее нет. Вероятность четных сбоев, которые не отлавливаются контрольными суммами не нулевая, следовательно это точно такая же игра вероятносями как и мои рассчеты.
Конечно при восстановлении после сбоев учитываются вероятности нарушения контрольной суммы для страницы (8кб), эта вероятность обычно измеряется восемью нулями после запятой в процентах.
Так что тут ты мимо кассы.

G>>Важно, потому что идемпотентные команды для клиента могут быть вовсе не таковыми для сервера. Да и не получится (очень сложно) все сделать только на идемпотентных командах.
M>Приведи, пожалуйста, пример команды которая одновременно идемпотентна и неидемпотентна.
Бросай курить эту траву.

G>>Сокращения затрат на железо — не факт (ты даже примера не привел), вполне возможна обратная ситуация. Сокращение лицензионных отчислений будет меньше увеличения затрат на разработку.
G>>Так что тут нет преимуществЮ есть только риск.

M>А ты когда-нибудь сам считал ТЭО для какого-нибудь проекта? Мне вот почему-то кажется что нет.
Да, считал, именно на таких ТЭО и отжимал говно всякое, которое преподносилось под видом манны небесной. Достаточно цену поддержки говна посчитать, которую обычно в ценник не включают и получается что говно оказывается в разы дороже промышленного решения.

G>>Это вообще чушь. Мастшабирование SQL Server делается прекрасно путем добавления дисков, памяти, процессоров (во что уперлось, то и добавляем). А для масштабирования nosql хранилищ надо ставить новые серверы, при этом снижается надежность хранения.

M>Если бы занимался эксплуатацией ты бы знал что нельзя просто взять и добавить mem/CPU/HDD. Хороший сервер неплохо сбалансирован и у него скорее всего не хватит слотов куда можно что-то добавить. В результате простое действие "добавить еще диск" сводится к десяткам килобаксов на новую железку.
Ну не надо свистеть, для HDD специальные хранилища, куда легко вставить еще один диск. Добавлять CPU и память сложно в железки. Но обычно покупают очень толстый хост и на нем нарезают виртуалки. Это экономит расходы сильно. В такой ситуации "добавить mem\cpu" проблемой не является.

G>>При этом SQL Server прекрасно масштабируется по объему данных просто доставлением дисков и, иногда, памяти. И то и другое относительно дешево.
G>>А для nosql в этом случае надо целые серваки покупать. Что на порядок дороже.

M>Если покупать топовые сервера то дороже, а если ширпотребные десктопные железяки то дешевле.
Да-да, вот ты такой приходишь в банк и говоришь — не покупайте топовое железо, покупайте "ширпотребные десктопные железяки".
Ты не забывай, что речь идет о корпоративной разработке, а не о говносайтах.

G>>100% ты не продашь такое, если заказчик хоть сколько-нибудь грамотный.
M>Т.е. в тех твоих многих историях про миграцию с MS SQL на noSQL все заказчики были неграмотные?

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

G>>Про констрейнты я говорил в ответ на твое утверждение что в базе нельзя контролировать.
G>>Ты пытаешься использовать классический прием демагогии. Задать два похожих вопроса, а потом делать вид что ответ на первый, также отвечает на второй наоборот.

M>Это один и тот же вопрос.
Это твои фантазии, это два вопроса, причем разных.

M>Констрейнты способны гарантировать целостность данных (== непротиворечивость в терминах приложения) только в том случае если большая часть логики приложения переехала в БД. А ты вместо того чтобы согласиться начал юлить.
Ты не читаешь? я же тебе писал, вычисляй нужные значения прямо в insert. Баланс будет сходится и в попугаях и в деньгах. Проверять ничего не нужно, нужно только правильно писать insert. Если базу и приложение делает один человек, то этого достаточно.

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

M>>GA/YM не всегда отвечают требованиям бизнеса.
G>Например?

Например не палить своих пользователей гуглу который продает их конкурентам.

G>Лайки можно и в sql хранить.

Флаг тебе в руки.

G>Это неверно. Вот есть бухгалтерия в которой три человека работают, они за год генерируют несколько десятков ГБ только проводок. А про документы молчу.
G>Вообще в корпоративной среде количество пользователей всегда ограничено сверху, а объем данных — нет. А в публичных сайтах бывает ровно наоборот.

Вот, ты уже признал что на бухгалтерии задачи не заканчиваются. Уже успех

G>Конечно при восстановлении после сбоев учитываются вероятности нарушения контрольной суммы для страницы (8кб), эта вероятность обычно измеряется восемью нулями после запятой в процентах.

И что? По твоей логике если вероятность не ноль, значит гарантии нет.

G>>>Важно, потому что идемпотентные команды для клиента могут быть вовсе не таковыми для сервера. Да и не получится (очень сложно) все сделать только на идемпотентных командах.
M>>Приведи, пожалуйста, пример команды которая одновременно идемпотентна и неидемпотентна.
G>Бросай курить эту траву.

А как тебя еще понимать, если у тебя команды то идемпотентны то нет.

G>Да, считал, именно на таких ТЭО и отжимал говно всякое, которое преподносилось под видом манны небесной. Достаточно цену поддержки говна посчитать, которую обычно в ценник не включают и получается что говно оказывается в разы дороже промышленного решения.

Сам ты, надо полагать, стоимость поддержки не учитывал? Типа вы поставите решение и оно будет дальше работать само, а развивать его вы не будеете?

G>Ну не надо свистеть, для HDD специальные хранилища, куда легко вставить еще один диск. Добавлять CPU и память сложно в железки.

Легко, ага, первые 8/16/32 диска а потом surprise слоты тоже заканчиваются.

G>Но обычно покупают очень толстый хост и на нем нарезают виртуалки. Это экономит расходы сильно. В такой ситуации "добавить mem\cpu" проблемой не является.

Это-какие-то мелочные задачи, если под них можно нарезать виртуалку. Тут как бы масштабированием и не пахнет.

G>Да-да, вот ты такой приходишь в банк и говоришь — не покупайте топовое железо, покупайте "ширпотребные десктопные железяки".

Банки известны своей крайней консервативностью в IT и стремлением закрывать все риски деньгами так что это не аргумент.

G>Ты не забывай, что речь идет о корпоративной разработке, а не о говносайтах.

Как ты выражаешься, это твоя фантазия. Начали обсуждение мы с типично вебной задачи.

G>Нет, там решения принимали программисты, внутренний заказчик им доверял, а потом уже ничего сделать не мог, только просить бабло на новое железо.

Т.е. заказчик все-таки неграмотный если послушал программистов?

G>Ты не читаешь? я же тебе писал, вычисляй нужные значения прямо в insert. Баланс будет сходится и в попугаях и в деньгах. Проверять ничего не нужно, нужно только правильно писать insert. Если базу и приложение делает один человек, то этого достаточно.

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

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

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

M>>>GA/YM не всегда отвечают требованиям бизнеса.
G>>Например?
M>Например не палить своих пользователей гуглу который продает их конкурентам.
Странно, топовые интернет магазины не очкуют GA и YaM на своих сайтах ставить.
Что же ты такое продаешь?

G>>Это неверно. Вот есть бухгалтерия в которой три человека работают, они за год генерируют несколько десятков ГБ только проводок. А про документы молчу.
G>>Вообще в корпоративной среде количество пользователей всегда ограничено сверху, а объем данных — нет. А в публичных сайтах бывает ровно наоборот.
M>Вот, ты уже признал что на бухгалтерии задачи не заканчиваются. Уже успех

Успех в чем? Все равно nosql нигде не подойдет в качестве основного хранилища.

G>>Конечно при восстановлении после сбоев учитываются вероятности нарушения контрольной суммы для страницы (8кб), эта вероятность обычно измеряется восемью нулями после запятой в процентах.
M>И что? По твоей логике если вероятность не ноль, значит гарантии нет.
Почему же? Есть закон больших чисел, который говорит что появление случайной величины за пределами трех дисперсий от матожидания в жизни не встречается. Увы, когда вероятности меряются процентами — наблюдать можно, когда вероятность 1*10^-8, то наблюдать можно только в огромном дата-центре где тысячи серверов. Но там есть бекапы на этот случай.
Нет смысла такое обсуждать в теме про БД, ни у кого тут таких масштабов не будет.

G>>>>Важно, потому что идемпотентные команды для клиента могут быть вовсе не таковыми для сервера. Да и не получится (очень сложно) все сделать только на идемпотентных командах.
M>>>Приведи, пожалуйста, пример команды которая одновременно идемпотентна и неидемпотентна.
G>>Бросай курить эту траву.
M>А как тебя еще понимать, если у тебя команды то идемпотентны то нет.
Еще раз: построить большую систему, где все команды на изменение идемпотентны — очень сложно, этим никто не занимается.

G>>Да, считал, именно на таких ТЭО и отжимал говно всякое, которое преподносилось под видом манны небесной. Достаточно цену поддержки говна посчитать, которую обычно в ценник не включают и получается что говно оказывается в разы дороже промышленного решения.
M>Сам ты, надо полагать, стоимость поддержки не учитывал? Типа вы поставите решение и оно будет дальше работать само, а развивать его вы не будеете?
Учитывал, но поддержку СУБД можно возложить на штатные средства (бекап, штатные админы) П поддержка приложения, которое гарантирует сходимость баланса в любой момент времени, гораздо дешевле поддержки приложения, которое подобные гарантии не дает.

G>>Ну не надо свистеть, для HDD специальные хранилища, куда легко вставить еще один диск. Добавлять CPU и память сложно в железки.
M>Легко, ага, первые 8/16/32 диска а потом surprise слоты тоже заканчиваются.
Ну ок, 32 диска по 1 ТБ, тебе не хватит?
Может приведешь хотябы примерные характеристики серверов под монгу (или другую субд с надежной записью) чтобы обрабатывать 1ТБ данных?

G>>Но обычно покупают очень толстый хост и на нем нарезают виртуалки. Это экономит расходы сильно. В такой ситуации "добавить mem\cpu" проблемой не является.
M>Это-какие-то мелочные задачи, если под них можно нарезать виртуалку. Тут как бы масштабированием и не пахнет.
Ты в том и прикол, что SQL нет необходимости горизонтально масштабировать очень долго. 60гб оперативки с 20 ядер хватит на ооооооочень долго. А монге этого хватит на 60гб базу данных (даже меньше).

G>>Да-да, вот ты такой приходишь в банк и говоришь — не покупайте топовое железо, покупайте "ширпотребные десктопные железяки".
M>Банки известны своей крайней консервативностью в IT и стремлением закрывать все риски деньгами так что это не аргумент.
Прям заговор против nosql.

G>>Ты не забывай, что речь идет о корпоративной разработке, а не о говносайтах.
M>Как ты выражаешься, это твоя фантазия. Начали обсуждение мы с типично вебной задачи.
Сорри, а откуда в вебе такие проблемы? Ты сделай для начала сайт, куда придет миллион человек одновременно, а потом уже будешь думать как масштабировать это чудо.
Вот посоны на StackOverflow вообще год жили на одном серваке, а потом еще год на двух.

G>>Нет, там решения принимали программисты, внутренний заказчик им доверял, а потом уже ничего сделать не мог, только просить бабло на новое железо.
M>Т.е. заказчик все-таки неграмотный если послушал программистов?
Заказчик сделал роковую ошибку что доверился программистам.

G>>Ты не читаешь? я же тебе писал, вычисляй нужные значения прямо в insert. Баланс будет сходится и в попугаях и в деньгах. Проверять ничего не нужно, нужно только правильно писать insert. Если базу и приложение делает один человек, то этого достаточно.

M>Отличная аргументация, зачот. Типа если базу и приложение делает один человек то все зашибись и констрейнты не нужны.
Даже не один человек, а одна команда.

	От:	brunoid
	Дата:	12.09.14 15:28
	Оценка:

От:	Softwarer	http://softwarer.ru
Дата:	12.09.14 15:57
Оценка:	7 (2) +3

	От:	brunoid
	Дата:	13.09.14 08:00
	Оценка:

	От:	wildwind
	Дата:	13.09.14 19:05
	Оценка:

	От:	paucity
	Дата:	14.09.14 17:43
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	16.09.14 05:54
Оценка:	31 (3)

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	16.09.14 07:21
Оценка:	+1

	От:	DarthSidius
	Дата:	24.09.14 00:50
	Оценка:	1 (1) +1