Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

NoSQL vs SQL, и при чем тут теорема CAP

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

Все современные технологии хранения данных можно разделить на следующие группы:

В этой статье мы рассмотрим общие различия между SQL и NoSQL.

Классика реляционных баз данных

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

Придумал реляционную теорию баз данных в 70-х годах XX столетия Эдгар Кодд, американский математик из IBM. Он положил в основу своей теории математическую модель, которая продолжает служить нам верой и правдой по сей день.

Однако при всех своих достоинствах данный тип хранилищ обладает рядом неприятных особенностей:
— реляционные базы плохо масштабируются, с ними крайне сложно создавать распределенные хранилища;
— проектирование крупных баз с множеством компонентов требует значительных усилий. Это приведение сущностей к нормальным формам и сложности в отображении связей типа многие-ко-многим. Такие схемы тяжело читать и понимать их бизнес-применение;
— эволюция схемы данных почти всегда отстает от новых потребностей бизнеса. Часто она успевает устаревать еще до выпуска новой фичи. Миграция на обновленную схему занимает безобразно долгие часы, в течение которых «сервер лежит».

Все эти сложности существуют по одной простой причине: реляционная модель была создана для хранения табличных данных. И для этих целей она прекрасно подходит. Но прошло уже почти полвека с момента изобретения модели реляций: за это время системы хранения данных давно успели вырасти из «простых табличек» в распределенных дата-монстров. Создавая свою теорию, господин Кодд явно не рассчитывал на такое.

Действие теоремы CAP в контексте SQL и NoSQL

В то время, как реляционные схемы полагаются на принципы ACID, все без исключения NoSQL хранилища опираются на другие принципы, описанные в теореме CAP. Для начала в ней утверждается, что любое хранилище данных имеет три базовых свойства:

— Согласованность данных (Consistency). То есть данные должны быть полными и непротиворечивыми (в том числе и во всех узлах кластера).

— Доступность (Availability). Грубо говоря, это скорость ответа сервера на наш запрос (для записи или чтения).

— Устойчивость к разделению (Partition tolerance). Это значит, что в случае разделения системы на несколько частей каждая из них, если она доступна, должна быть в состоянии работать автономно, отдавая корректный отклик и предоставляя свои данные. Обрыв связей в кластере не должен влиять на итоговую работу.

Теорема CAP сообщает нам, что из этих трёх компонентов мы можем получить только два. Либо в той же пропорции 2:1 балансировать между этими составляющими: улучшение характеристик по одному из свойств влечёт за собой ухудшение в каком-то другом. Чтобы лучше понять силу этой теоремы, представьте себе распределенное хранилище, в котором вы пытаетесь без тормозов по производительности обеспечить 100% согласованные данные (на чтение и запись).

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

На самом деле, практически все NoSQL технологии были рождены с целью решить проблему устойчивости к разделению, то есть эффективно работать на кластерах. Реляционная модель не в состоянии справиться с этой задачей, так как была создана для других целей и в других условиях. У вас не получится «просто отпилить парочку-тройку таблиц или спокойно их партицировать в соседний кластер», а потом отправиться пить кофе-чай. Welcome to Hell.

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

Истинная суть теоремы CAP проявляется именно в условиях распределенной системы. Очевидно, что создавать неустойчивый к разделению кластер — лишено какой-либо практической пользы. То есть кластер априори должен создаваться устойчивым к разделению. Понимание этого факта позволяет нам увидеть теорему CAP в новом свете: из согласованности и доступности можно выбрать только что-то одно — или же использовать разумный компромисс между этими двумя пунктами (а не тремя, как можно подумать из оригинального определения).

Вторая задача, которую пытаются решить идеологи NoSQL технологий, — повышение доступности, то есть получать быстрый ответ сервера. За счет чего эта задача решается в агрегатных и графовых базах, я напишу в следующих статьях цикла.

Больше информации по этим вопросам можно найти, изучив понятие итоговой целостности и подхода BASE.

Общие свойства технологии NoSQL

Ниже я напишу о самых существенных на мой взгляд общих свойствах всех NoSQL технологий.

1. NoSQL противопоставляются реляционным базам (как можно догадаться из названия). Если подытожить всё сказанное выше в пояснениях к теореме CAP, то мы получим следующую картину. Условия существования баз данных изменились. В результате возникли новые проблемы, справиться с которыми классические SQL базы не могли. За короткий период времени родились целые семейства баз данных, целенаправленно отказавшихся от реляционной структуры. Мы получили ориентацию на кластеры, быстрый ответ сервера и итоговую целостность.

2. NoSQL имеют неявную схему данных — этот факт часто пугает инженеров, привыкших работать со строгой схемой реляционных баз. Я часто слышу аргументацию в стиле «в такую базу можно писать что угодно в любом порядке, это же хаос». На самом деле бардак можно устроить в любом месте, было бы желание. Но все данные, которые вы пишите, а потом читаете, имеют определенную структуру. У вас есть именованные поля, в них хранятся данные определенного типа. Проблема состоит лишь в том, что теперь контроль за вашей структурой перекладывается с СУБД на приложение: вы сами можете установить в нём любые правила валидаций.

Особый интерес вызывает ситуация, когда с базой работают сразу несколько приложений, каждое из которых хочет писать и читать неявно-структурированные данные. Очевидно, что рано или поздно между ними возникнет конфликт форматов. В этом случае можно поступить по-разному:
— разграничить зоны ответственности каждого приложения: в разные области схемы данных должны иметь доступ разные приложения;
— использовать идею шаблона Прокси: обернуть нашу драгоценность (базу) в отдельное приложение и общаться с ним через веб-сервисы.

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

Ещё одна отличительная особенность неявной схемы данных заключается в её эволюционности. Вы можете вносить коррективы в структуру данных на лету, в ногу с потребностями бизнеса. В реляционных базах менять архитектуру — всегда накладно. Это физически тяжело. Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен. Но ты знаешь, что Mongo (документная база) или Vertica (семейство столбцов), или Neo4j (графовая база) могли бы решить эту задачу за 0,0000x сек. И это удручает в работе с SQL базами.

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

Однако обратная сторона этой медали заключается в том, что вам всё ещё нужно уметь читать и интерпретировать нужным образом ранее записанную информацию «устаревших» форматов. Что можно сделать, чтобы уменьшить боль неминуемого рефакторинга NoSQL баз:
— относиться серьезно к неявной схеме данных еще на моменте ее проектирования;
— покрывать тестами вашу неявную схему данных в базе, проверяя все нужные форматы содержимого;
— не надеяться, что отказ от старых форматов и миграция на новые будет легче, чем в реляционной модели: использование неявной схемы данных не избавляет вас от этой боли. Перепроектирование границ агрегата или создание новых узлов графа из атрибутов существующих узлов ничуть не лучше классического ALTER в базе SQL: вам всё равно придётся последовательно обходить значительную часть записей базы и исправлять их.


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

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

P.S. Очень доходчиво и подробно теорема CAP описана в книге «NoSql: новая методология разработки нереляционных баз данных» (Прамодкумар Дж. Садаладж, Мартин Фаулер). Подход BASE и сравнение технологий NoSQL также можно посмотреть в книге «Графовые базы данных» (Ян Робинсон, Джим Вебер, Эмиль Эифрем).

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Не обижайтесь, но по итогу как в анекдоте:
Я вижу, что переубедить вас не удастся, поэтому сразу перейду к оскорблениям.

Техническая статья на доу! Слава Наталье Ниште!

Это не обзор, это агитация за NoSQL (вероятнее всего, MongoDB). Причём не очень удачная.

Но прошло уже почти полвека с момента изобретения модели реляций: за это время системы хранения данных давно успели вырасти из «простых табличек» в распределенных дата-монстров. Создавая свою теорию, господин Кодд явно не рассчитывал на такое.
Реляционная модель не в состоянии справиться с этой задачей, так как была создана для других целей и в других условиях.

Не надо так. У вас по всей статье такое вот грубое и примитивное нагнетание эмоций на ровном месте. Реляционные СУБД (это не СХД, кстати) никогда не были «простыми табличками».

В то время, как реляционные схемы полагаются на принципы ACID, все без исключения NoSQL хранилища опираются на другие принципы, описанные в теореме CAP.

Монга и транзакции — это боль, мы в курсе.

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

Однако обратная сторона этой медали заключается в том, что вам всё ещё нужно уметь читать и интерпретировать нужным образом ранее записанную информацию «устаревших» форматов.

Как будто в обычном MySQL нельзя вместо ALTER TABLE, выполняющегося восемь часов, тупо создать новую табличку рядом со старой и писать новые данные туда. А старые данные оставить валяться в новой структуре. Вот уж действительно, бардак можно устроить где угодно.

www.facebook.com/...an/posts/1149980465080002
Без этого пост был бы неполным.

Начала новую серию статей: пока планирую в общей сумме отделаться тремя выпусками.
Отдельное спасибо Славе ) Без тебя я бы не справилась.

Классический срач в комментариях прилагается.

UPD.
удивительным образом удалось заткнуть глотки ревнителей реляционных схем ссылкой на производительность сильносвязанной структуры https://neo4j.com/.../how-much-faster-is-a-graph-database-re.../

438 коментарів

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

А тем временем в замке шефа...
Quantifying and Generalizing the CAP Theorem.
Придают количественную трактовку терминам Consistency и Availability, и получают обобщение CAP на непрерывный случай.

Vertica (семейство столбцов)

А вертика-то каким боком сюда попала? Она же реляционная.

набор таблиц, имеющих отношения (relations) друг с другом
Який прикра помилка на самому початку!
Таблиці це й є відношення (relations), від яких реляційна модель отримала назву. А «друг с другом» вони мають не відношення, я зв’язки (relationships).

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

А что лично Вы узнали интересного сугубо с технической точки зрения?)

online DDL для MySQL
Давайте сразу определимся с терминологией. DDL, DML ортогональны понятию транзакция. Для Вас сразу вопрос — с чего начинается транзакция вообще и в какой момент начинается транзакция для оператора DDL? Теперь продолжим по тексту.
Итак, не во всех СУБД она недоступна для чтения, иными словами в процессе работы «Alter table» возможно чтение этой таблицы из других сессий.

Про MySQL я сам много узнал) Последний опыт был в 3-ей или 4-ой версии с ISAM-таблицами, чтение из которой эффективно блокировало запись и наоборот. Это было несерьезно.
Я хотел бы прокомментировать. DDL — это, по сути блок: {commit; DDL statement; commit;}, поэтому если DDL где-то упал, предыдущее состояние закоммитилось все равно.
В Оракле одиночный селект не начинает транзакцию или, точнее, выполняется в отдельной мини-транзакции, для которой не выделяются ресурсы и которую не нужно откатывать.
Для м-ра Левинсона это оказалось откровением, похоже)

Да и вообще было бы замечательно прошерстив комментарии к этой статье выделить тезнически стоящие на их основе сделать новую статью, но тут нужно отдать должное автору — она может это сделать, а я судя по всему нет :)(

А для меня как «интересующегося» статья оказалась полезной.
В том плане, что я хотя бы про принципы ACID почитал, уровни изолированных данных и теорему CAP (в общем, на Википедии провёл больше времени, чем на чтение текста статьи).
А также кучу полезных комментариев. Спасибо всем.
Будем стараться для каждой задачи использовать тот инструмент, который лучше подходит (исходя из опыта, разумеется).
Понятно, что в будущем придётся не только Википедию почитать, но раз из статьи были туда ссылки...
Вот только вряд ли меня можно было бы отнести к

стойким духом инженерам
, скорее таки к начинающим, хотя работал и с реляционными базами, и с NoSQL (совсем чуть-чуть).

Читая как «страшен» изъян ALTER TABLE, с намеком что надо вообще отказаться в пользу NoSQL, приходит на ум аналогия — что от кривостей пхпа надо отказаться заменив его хаскелем.
ну а от перхоти ессно гильотина самый надежный способ.

а насчет того чем оборачивается безсхемный старт потом, когда проект пройдет пару продакшн релизов, мне еще вот такая статья с хабра вспомнилась:
Мой опыт внедрения Apache Cassandra

Безсхемные бд удобны когда нет времени думать, а надо сразу что-то педалить.
Огребать придется потом. А может к тому времени проект просто умрет, и никто и не узнает, с чем бы пришлось столкнуться при разработке его версии 3+ :)

то есть NoSQL — хорош для стартапов. может в этом секрет неумолкающего хайпа — те что на нем педалили MVP да POC — просто не узнали чем оплатили кайф безхемной БД в будущем, зрелом проекте, не узнали кредит какой неподъёмности взяли, потому что стартап — не взлетел.

и на следующем стартапе радостно — NoSQL конечно!. и он тоже не взлетел. и так после нескольких раз вырабатывается только положительнейшее отношение к этому классу БД.

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

Лякалки існують що там, що там. Криві руки ще ніхто не відміняв.

Криві руки ще ніхто не відміняв.
Це так і не так.

У кожної технології є фундаментальни характеристики оминути котрі без болю — ну дуже важко.

Ось, ще пригадав

Почему эти ваши модные NoSQL решения не так уж хороши
цитую:
Пробовали MongoDB. К счастью, с этой СУБД мне пришлось работать совсем недолго. MongoDB не выдерживает никакой критики, и ее недостатки, похоже, поняли уже все, кроме, разве что, самых упоротых программистов на Node.js. Вручную шардированный PostgreSQL, который, напомню, уже давно умеет формат JSONB, с самым тупым и никем не протестированным скриптом на Python для автофейловера, будет куда более удачным выбором, чем MongoDB. ... Выбрав PostgreSQL, вы получите все тоже самое, только куда более стабильное, не теряющее данные, а также с нормальными локами, вьюхами, транзакциями, джоинами и вот этим всем.

Коли людина із «SQL головного мозку» приходить на NoSQL рішення і вимагає від нього теплого зампового няшного SQL, то звісно ж трапляються факапи. Чи треба в NoSQL рішеннях писати більше ручного коду? Так. Бо інструмент простіший. А чи можна отримати плюшки від NoSQL рішень? Так, ще й які. Але треба ретельно вивчати інструмент і міняти мислення. Без цього завжди буде дупобіль.

А що таке

«SQL головного мозку»
?
Можете навести якісь приклади?)

Це коли всі задачі людина вирішує через SQL та можливості реляційних БД. Треба зробити зв’язок двох сутностей? Значить мусить бути дві таблиці та джойн. Ніяк інакше. Дерево? Таблиця виду id, parent_id? Як ні? о_О

Це коли всі задачі людина вирішує через SQL та можливості реляційних БД
всі задачі неможливо вирішити НІЯКОЮ технологією.

Срібної кулі не існує.

Але коли RDBMS вирішує 95% задач, а NoSQL 5% інших — то у кого NoSQL головного мозку?

у того що впевен RDBMS вже не модні, застарілі, і такє інше.

Значить мусить бути дві таблиці та джойн.
і? що саме вас жахає в джойнах?

ви не вмієте проектувати схему RD? ви не хочете розбиратись як працює RD?
і тому ви вірите що якась монга полегшить вам життя у реальних проектах?

Срібної кулі не існує.
Дякую, Кеп!
Але коли RDBMS вирішує 95% задач, а NoSQL 5% інших — то у кого NoSQL головного мозку?
Не знаю
у того що впевен RDBMS вже не модні, застарілі, і такє інше.
Ви про кого?
і? що саме вас жахає в джойнах?
А хто сказав, що мене щось жахає?
ви не вмієте проектувати схему RD?
Ви з якою метою цікавитеся?
ви не хочете розбиратись як працює RD?
Хто вам таке сказав?
і тому ви вірите що якась монга полегшить вам життя у реальних проектах?
Якщо знати всі позитивні та негативні сторони цієї технології та приміняти її у відповідних задачах, то так, я вірю що вона мені полегшить життя.

Сподіваюся, з лірикою закінчили. А тепер час цікавих історій. Робили ми одну систему для банку, яка оперує кредитними історіями. Туєва хуча даних, які експортуються із різних систем в XML форматі. Коли ми показали структуру сховища цього проекту, в якій було лише п’ять примітивних табличок, нам сказали що ми якісь шахраї. Ми посміхнулися та через три тижні успішно закінчили проект. Знаєте чому? Тому що замість того, щоб розкладати XML на сотні таблиць, ми зберегли ці XML в базу, проіндексували, витягли в окремі таблички необхідні фінансові дані та написали більшість коду на xquery. Якщо б ми хворіли на SQL головного мозку, то ми б робили той проект пів року мінімум.

Схема одна, але включає декілька варіантів структури. Дані попадають шляхом імпорту файлів звісно ж.

Декілька — це приблизно 10 варіантів розгалуження.
Документи були збережені як є, без змін. По деяких шляхах були зроблені індекси, з деяких даних були витягнуті ідентифікаційні дані й складені в окрему таблицю.

Туєва хуча даних, які експортуються із різних систем в XML форматі.
цитую себе:
а NoSQL на ділі- НЕ альтернатива RD, а рішення для вузьких, нетипових для RD задач. Коли немає потреби в функціоналі RD, а тра — просто в якусь купу звалити різнорідну інформацію.

але цікавіше почути від вас цифри:
наприклад розмір отої туєвої хучи даних. 5 Тб, як у прикладі в цій темі?
чи там така хуча що майже вся влазить в оперативну пам’ять сервера БД?

Тому що замість того, щоб розкладати XML на сотні таблиць, ми зберегли ці XML в базу
проіндексували — для full-text search, чи встановили ElasticSearch якийсь?
Якщо б ми хворіли на SQL головного мозку, то ми б робили той проект пів року мінімум.
Якщо б ми хворіли на SQL головного мозку, то ми б робили той проект пів року мінімум.
я не зрозумів — чому ви такі здорові використали — RDBMS а не NoSQL?

і чому ви не прочитали:

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

Резюме:
ви привели приклад де RDBMS добре впоралася.

Хоча ж специфіка теж була мною вказана

Наприклад MongoDB — добра коли треба централізовано тримати логі.
ви ж потім не змінювали ніякі данні у тих XML, коли вони вже попали в базу?
Витягли цифри у таблиці — та й все. До речі — а навіщо? ну й шукали б їх у XML, коли потрібно ;)
а інше я так зрозумів — довідниковий хлам.
Якщо б ми хворіли на SQL головного мозку, то ми б робили той проект пів року мінімум.
хлам да, аналізувати можна місяцями.

ви його вирішили — не аналізувати, а наколупати з нього ізюму.

і? до чого тут ваше «SQL головного мозку»

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

навіть зараз я таку таблицю завів :D

наприклад розмір отої туєвої хучи даних. 5 Тб, як у прикладі в цій темі?
Не в курсі, який розмір зараз. На початку було декілько мільйонів документів.
проіндексували — для full-text search, чи встановили ElasticSearch якийсь?
Який фултекст, ви що, смерті сервера хочете? Індексування окремих шляхів XML + винесення основної ідентифікації в окремі таблиці, які були проіндексовані окремо. Все індексування штатними можливостями.
я не зрозумів — чому ви такі здорові використали — RDBMS а не NoSQL?
Вимоги клієнта :)
ви привели приклад де RDBMS добре впоралася.
Навпаки, я привів приклад, де впорався не RDBMS та SQL, а альтернативний підхід та альтеративні мови запитів (xQuery)
і? до чого тут ваше «SQL головного мозку»
Читайте нижче коментар ;)
Навпаки, я привів приклад, де впорався не RDBMS
як це, коли ви написали:
Вимоги клієнта :)
та
Ми посміхнулися та через три тижні успішно закінчили проект.
на RDBMS
Індексування окремих шляхів XML
RDBMS з цим впоралася, чи ні?
та SQL
SQL — то декларативна мова. зі всьома перевагами, та недоліками перед — імперативними мовами.

ви вирішили частину роботи зробити на імперативній мові, а не на SQL.

і що тут дивного, коли більшість програмістів так і робить — з ORMами чи без?

тобто якщо ви про SQL — то тоді холівар не про БД, а про

Декларативна(функціональна) vs Імеративна парадігми

На початку було декілько мільйонів документів.
цікавить розмір у байтах.

мільйони рядків у БД — то дрібне.

RDBMS з цим впоралася, чи ні?
Так, впоралася. Але впоралася не завдяки SQL.
SQL — то декларативна мова. зі всьома перевагами, та недоліками перед — імперативними мовами. ви вирішили частину роботи зробити на імперативній мові, а не на SQL.
Не сказав би, що xQuery то імперативщина... Зараз все так змішалося вже...
цікавить розмір у байтах.мільйони рядків у БД — то дрібне.
Документів, не рядків. Один рядок — один документ. Документи різні, точний об’єм не скажу, не пам’ятаю просто.
Так, впоралася. Але впоралася не завдяки SQL.
ну то й добре.

а мовою RDBMS можна й не користуватись.
більшість програмістів і не користуєця, а працюють з RDBMS через ORMы

Не сказав би, що xQuery то імперативщина...
так, xQuery, xPath, як і RegExp, не імеративні.

але ж ви їх викликали звідки? з якого оточення?

ну я с джави працював з xDB, формуючи та викликаючи xPath запити до неї.
то я писав декларативно? чи все ж на імперативній джаві?

ще приклад:
SELECT то теж не імперативщина.

але коли його формують з джави, чи з пхп, отримують відповідь, та знову формують якийсь INSERT — то у цілому це який код буде — імперативний чи декларативний?

ще
LINQ у С# - декларативний DSL. але сам С# - який?

Документів, не рядків. Один рядок — один документ.
?
так я й написав про рядки. бо так і зрозумів що в вас просто типова таблиця «для імпорту». де на кожну окрему, логічно закінчену порцію інформації — один рядок в таблиці.

так і для csv роблять, і xls.

так я якось робив і коли з «дампа» Монгі імпортував.

точний об’єм не скажу
а він теж не важливий, як я зрозумів з ваших пояснень.

вся фішка — у індексуючих таблицях.
що роблять і не заради xml.

Наприклад класика — таблиця з кодів атрібутів товарів у ел магазині.
щоб фільтри хутко працювали.

)) А що поганого в підході типу id, parent_id?

Нічого. Але існують й інші підходи.

Звичайно що існують інші підходи, але це ж Ви написали в контексті

«SQL головного мозку»
Ви ж погодитесь з тим що підхід «id, parent_id», тобто зберігання усього дерева в одній табличці є найпростішим і найоптимальнішим засобом зберігання, а за допомогою ієрархічних запитів можна вирішити будь-які задачи? Тобто якщо є база, то так і треба робити, якщо вже немає, тоді треба придумувати щось самому?
є найпростішим
Так
найоптимальнішим засобом зберігання
Не факт, не факт. Якщо треба знайти шлях від певного елемента до початку дерева, то тут ця «найоптимальніша» структура починає буксувати.
Спробуйте за допомогою лише id/parent_id попрацювати із XML-структурами.
попрацювати із XML-структурами.
тобто у вас «XML головного мозку»!

ви всюди пхаєте отой XML :D

Якщо треба знайти шлях
то треба його і зберігати так, щоб було зручно його шукати.

Простецьке правило проектування схем RDBMS:
Покажіть які репорти ви хочете отримувати за допомогою БД.

от як це невідомо, а так буває у системах документообігу — тоді Lotus Notes — добрий вибір. або щось більш модняве.

тобто — коли мета збереженная невідома — тоді просто складуємо у купу. розгрібати будемо потім, як воно не згниє до того часу.
правда, це і у RDBMS можна робити :D

тобто у вас «XML головного мозку»!
В тому числі :) Просто це найкращий приклад того, де буксують інші «класичні» варіанти.
Покажіть які репорти ви хочете отримувати за допомогою БД.
Ой, OLAP хочу.
правда, це і у RDBMS можна робити :D
Зазвичай це і є перша реалізація :D
Просто це найкращий приклад того, де буксують інші «класичні» варіанти.
вже написав — це звичайний, класичний варіант і є.

просто ви вигадали собі якихось міфічних йолопів «з SQL головного мозку» та регочете з них :)

ну то як кацапи : «Представляете, хАхлы верят что древние укры выкопали Черное море! идиоты»
або піндосів — «Нууу тупые!»

от так і ви вірите що хтось витрачав би місяці на парсінг веб сайту та збереження його DOM дерева, у таблицях 6NF,
коли треба просто зграбати прайс з нього.

sys_connect_by_path в Оракле, там нема чому буксувати. В PostgreSQL колись я для цього писав свої процедурні міні-розширення, але теж все працювало нормально.
XML можна зберігати в структурах, повязаних з XMLType. Той же самий XPath там є, і багато іншого, хоча це суттєво ускладнює і написання коду, і подальшу підтримку. Я шось не памятаю, щоб бачив десь таку цілісну реалізацію. З іншого боку, валити XML в BLOB теж не вважаю дуже добрим рішенням. Але якщо таке рішення працює і реалізує всі вимоги, то чому би й ні.

валити XML в BLOB теж не вважаю дуже добрим рішенням. Але якщо таке рішення працює і реалізує всі вимоги, то чому би й ні.
як я зрозумів — вони написали свої індекси до них.

мабуть приблизно як у проекті котрий я згадував у цій темі :)

RDBMS — руліт! можна свою Монгу на ній зробити, а можна xDB (EMC Documentum xDB).

причому — всього за 3 тижні!

і хто після такого каже що RDBMS незручна для нетипових для неї проектів?

як я зрозумів — вони написали свої індекси до них.
Індекси звичайні, ми просто зробили окрему таблицю для ідентифікаційних даних людини. Бо індексування по XML хоч і є, але буде займати більше часу, ніж наша примітивна реалізація, особливо на вставці нових даних.
RDBMS — руліт! можна свою Монгу на ній зробити, а можна xDB (EMC Documentum xDB).
Не все так райдужно. Деякі операції реально будуть виконуватися довше. Проводили тестування, виграв гібрідний варіант — один документ на одній строчці, індекс тільки по невеличкий кількості елементів.
і хто після такого каже що RDBMS незручна для нетипових для неї проектів?
Я більше про SQL, а не про RDBMS. SQL для XMLDB використовувати можна, але краще зробити собі сєпуку.
Я більше про SQL, а не про RDBMS
люди сидять на Hibernate, Doctrine та усяких Active Record і не розуміють про що ви. який такий SQL? навіщо?
;)
один документ на одній строчці, індекс тільки по невеличкий кількості елементів.
я так і зрозумів. і роблю так вже з кінця 90их, коли треба імпортувати у систему щось з текстових файлів.

в чому ваше ноу-хау, «свіже мислення»?

здоровий глузд да, бачу — «не треба парсити все, що можна розпарсити»

люди сидять на Hibernate, Doctrine та усяких Active Record і не розуміють про що ви. який такий SQL? навіщо?;)
Є такий тип людей, бачив, знаю. Й граблі в них такі цікаві, з визирунками...
в чому ваше ноу-хау, «свіже мислення»?
Яке ноу-хау? Ви про що? :) Всі базові алгоритми вигадані ще 40 років тому, наша участь тільки діставати їх із шухлядок, витрушувати пил, модифікувати та використовувати ще раз.
Є такий тип людей, бачив, знаю. Й граблі в них такі цікаві, з визирунками...
то більшість. і нічого — світ не впав :)

купа програмного забезпечення працює роками, розвиваєця :)

Яке ноу-хау? Ви про що? :) Всі базові алгоритми вигадані ще 40 років тому,
ну ви казали про якесь зміну мислення.

а я її, цю зміну не побачив :)

от і перепитую — що саме у вашому прикладі демонструє нове мислення.

у чому саме воно було, те нове мислення?

Зміна з «хочу писати в NoSQL в спосіб який звик (SQL)» на «обрав інструмент, розумію переваги й недоліки, не намагаюся з нього зробити RDBMS»

мабуть я тупий.

я нічого цього не побачив з того що ви розповіли.

ви використали RDBMS як її використовує тьма людей, навіть тупий я.

і про

«хочу писати в NoSQL в спосіб який звик (SQL)»
вже писав. причому як про самі данні, які й вимагають підходів до їх обробки,

так і про більшість програмістів які не мають звичкі до SQL бо користуюця ORMами працюючи з RDBMS. за що на них лаюця DBA.
тобто ви вигадали поширеність цієї звичкі

Не все так райдужно.
Отут я згоден. BLOB/CLOB — це майже завжди трохи чужерідний елемент в базі. Є деякі очевидні мінуси. Якщо дані в XML інтенсивно оновлюються або просто якісь внутрішні записи змінюються, це призводить до інтенсивної генерації редо, аж ніяк не порівняти з оновленням звичайних полів. Якщо виконується видалення, то виникають проблеми з «вивільненням» місця. Також кожний блоб займає один (мінімум) чанк, і вільне місце в чанку втрачається відразу. Ріст даних за рахунок додавань та оновлення існуючих дуже часто призводить до «вспухання» бази. Можна дуже швидко отримати терабайтну базу, маючи зовсім невеликий обєм даних насправді. Ефективно можна працювати тільки з одним рядком, бо навіть якщо написати свої функції (або використовувати той самий XPath), це буде не SQL, а процедурний код, тобто переключення контекста і обробка датасета порядково гарантовані.
Для таблиці в цілому є теж деякі обмеження, але то вже таке)
Якщо все це окей, або не впливає на фукнціонування, то можна писати)

В Ораклі сидять не тупі лайнокодери, XML можна легко розкласти на запчастини, записати в табличний вигляд та проіндексувати. Що вони з успіхом й роблять. Доречі, їх версія xQuery не вміє updating functions, вони робляться тільки через pl/sql. Це капець як незручно... Може щось і змінилося...

В Ораклі сидять не тупі лайнокодери, XML можна легко розкласти на запчастини, записати в табличний вигляд та проіндексувати.
Так це можна один раз зробити в процесі імпорта XML-документа, чи ні?)
«Update function fn:put.» не підтримується в 12с також. Це цілком зрозуміло, бо для Оракла це просто набір байтів, який читається і записується одним шматком. Якщо розмір чанка 32К, приміром, то 32К читається, потім після змін пишеться в BLOB. Якщо це звичайний стовпчик, то він оновлюється в блоці даних безпосередньо, тобто набагато менше змін.
Так це можна один раз зробити в процесі імпорта XML-документа, чи ні?)
Наскільки я пам’ятаю, Оракл це робить під капотом автоматом... Хоча можу помилятися, бо дуже багато іншої інформації в голові...
хоча це суттєво ускладнює і написання коду, і подальшу підтримку
xQuery рулить.

мене не вразив :)
ну то вже справа смаку.

звісно що зручніше аніж ходити циклами по гілках дерева.

мене не вразив :)
Краща мова, яку я вчив за останні надцять років...

та ну :)

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

махнув рукой — два цикли та одна рекурсійна процедура — і отримую те що треба. витратив менше часу чим на оте гугління.

звісно, замість одного рядка на xPath вийшло 20 на загальній імперативній мові.

але взагалі цікаво — декларативний SQL вам не подобаєця, а от regexp для XML від якого очі можуть повилазити — вам подобаєця.

Ви нічого не плутаєте? о_О

XQuery Example:
for $x in doc("books.xml")/bookstore/book where $x/price>30 order by $x/title return $x/title
вам же ж не подобаєця цей (S/X)QL?

то мабуть вам подобаєця xPath
a[//tr/@data-id=@data-id] .//actors/actor[ends-with(., 'Lisa')]

трохи не повилазили. ну, очі.

в справжньому SQL ще гірше виглядає. Якщо ще зверху якісь трансформації, то взагалі капець. Гірше ніж модель. Хоча я завжди думав, що гірже ніж модель, нічого вже не може бути)

Мова в мовi, так. Регеспи теж виглядають не дуже, в кодi на унiверсальнiй мовi.
Ну от тепер i посеред SQL треба звикати до xpath 😁
Xml — вже точно нiкуди не дiнеця

Цiкавiше що наш xmlщик не бачить що обидва QL однаковi за принципами.

Для цього я й обрав самий очевидний приклад.
Але як i прогнозувалося — той що починаэ з снобiских заяв та претензii на нове, свiже мислення — буде й надалi вважати всiх дурнями.

Цiкавiше що наш xmlщик не бачить що обидва QL однаковi за принципами.
:D Ви реально думаєте, що я не бачу?
Але як i прогнозувалося — той що починаэ з снобiских заяв та претензii на нове, свiже мислення — буде й надалi вважати всiх дурнями.
Мені знову здається, що ви не зрозуміли того, що я намагався донести. Вихопили знайомі слова та почали сперечатися. Я не казав, що SQL чи RDBMS погані, NoSQL рулить. Я казав, що люди підходять до рішення задачи не розібравшись в інструментах. А потім плачуться, що в них щось не вийшло. Треба вивчати інструмент, можливості, підходи. Я нічого не казав про нове та свіже мислення, я казав про те, що треба міняти мислення, коли задача не співпадає із звичною.
Ви реально думаєте, що я не бачу?
просто зробив припущення, що якщо людині не подобаєця SQL але вона в захваті від XQuery — то людина не бачить що семантичні підходи в них — однакові:

декларативний опис:
ДЕ шукати данні
ЯКІ саме «одиниці» данних потрібні
ЩО тра зробити з кожною «одиницею», або у цілому з отриманною їх групою.

Я казав, що люди підходять до рішення задачи не розібравшись в інструментах.
це в більшості випадків так. експертів, сіньорів завжди мало.
що треба міняти мислення, коли задача не співпадає із звичною.
1. є данні. які треба зберігати у цілому, але не треба їх формалізувати повністю.
2. данні вже структуровані. але не так як вимагає таблична БД.

я не побачив незвичності. в ентрепрайз світі xml використивуєця давно. самі оті XPath та XQuery з’явилися з потреб частої обробки xml. Оті всі ETL, XSLT.

Задача така типова, в ентерпрайз світі, що розробники RDBMS додають все більше функціоналу для обробки XML (та JSON) сервером БД, а не клієнтом.

додають — не без проблем, не без ось такого коду
SELECT t.c.value('@obj_id', 'INT') FROM @xml.nodes('objects/obj') t(c) WHERE t.c.value('@obj_id', 'INT') < 0 )
та проблем: XML, XQuery и тройная печаль с производительностью

але. якби то була рідкісна, нетипова задача, то ніхто б не розширював функціонал RDBMS.

взагалі, вся ця тема вийшла цікава.
я не взнав більше того що знаю про світ NoSQL, зате зробив собі чимало практичних нотаток про RDBMS :)
та й про світ NoSQL більш практично пишуть ті що вказують на недоліки, а не ті що нахвалюють :)

просто зробив примущення, що якщо людині не подобаєця SQL але в захваті від XQuery — то людина не бачить що семантичні підходи в них — однакові.
Я нейтрально відношуся до SQL, бо не працював з ним вже дофіга років. :)
та й про світ NoSQL більш практично пишуть ті що вказують на недоліки
Це не недоліки. Це особливості дизайна, які не були враховані в архітектурі + звички мислити реляційно там, де реляції або неможливі взагалі, або їх треба робити в інший спосіб. Наприклад, в NoSQL рішенні дані можуть дублюватися. І це треба сприймати як данність, інакше ми можемо просісти по швидкості. А як боротися із дублями? Один із класичних способів — не допускати їх. І тут є рішення, перевірене десятиріччями — RDBMS. :D Але в нас жеж NoSQL рішення. Можна наплювати на це. Є дублі й є, пофігу. А є третій варіант (не останній, але я більше не буду продовжувати думку) — створити лінивий колектор дублів, який буде працювати тоді, коли є звертання до даних (або коли немає). Він з часом приведе найбільш активно використовуємі дані до притомного вигляду. Йдемо далі. Наприклад, є декілька множин, які мають між собою певні реляції. Як вирішує проблему запитів звичайний програміст в NoSQL рішенні? Будує аналог SQL та RDBMS. :D Ну логічно ж! А для мене це виглядає трохи по-іншому. Необхідно побудувати ще декілька множин на основі первинних, які дозволяють працювати із запитами найефективніше. Тобто я не боюся множити дані, дублювати їх, бо мені треба досягти певної швидкості без втрати зручності. Доречі, materialized view з’явилися в RDBMS не просто так :)
Як вирішує проблему запитів звичайний програміст в NoSQL рішенні? Будує аналог SQL
вже побудовано:

XQuery, Cassandra Query Language, GQL for MongoDB і т.д.

Бо декларативний опис манупулювання данними — то зручно. Ви самі від нього у захваті :D

але чомусь слідуючим рядком кажете що він вельми поганий.

цього протиріччя я не можу збагнути.

то ви в захваті чи ні?

Необхідно побудувати ще декілька множин на основі первинних, які дозволяють працювати із запитами найефективніше.
тобто або"проіндексувати" первинні данні, або «закешувати» :)
якщо вони нема потреби в інвалідації — то так і робиця.
Тобто я не боюся множити дані, дублювати їх
а хто боїця?

бояця проблеми що вказав — інвалідація данних коли змінилися первинні данні.

кредитна історія — незмінна. «що було, те було».

Є дублі й є, пофігу
ну коли пофігу, то пофігу.

або як у статі — втратили данні? та пофігу!
«так чому б їх тоді відразу не зберігати в /dev/null?»

Доречі, materialized view з’явилися в RDBMS не просто так :)
ще один варіант — кеша :) - This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages (Wiki)
бо мені треба досягти певної швидкості без втрати зручності.
це всім треба.

Давайте я розшифрую
for $x in doc("books.xml")/bookstore/book where $x/price>30 order by $x/title return $x/title

for $x in sequence
Для кожного $x з переліку
doc("books.xml«)
Посилання на документ
/bookstore/book
Шлях XPath всередені документа, поверне всі ноди book всередені bookstore
where $x/price>30
 Де в книжки ціна більше 30
order by $x/title
Відсортувати за назвою
$x/title
повернути ноди <title/>

Відтворюємо документ bookstore

<bookstore> <book> <title/> <price/> </book> </bookstore>

Ніяких регекспів :)

a[//tr/@data-id=@data-id]
Оце JOIN по атрибуту @data-id двох переліків — тегів «a» та тегів «tr»

Так, мені подобається XPath, бо він доволі лаконічний.

MUMPS ще лаконiчнiше. Тому й не вразив xpath.

А пояснення шо ви привели — зайвi. Тому хто хоч трохи користувався SQL все й так очевидно. Тому й не вразив xquery

XQuery це не тільки QL, це ще й офігенський довісок у вигляді модулярності, функціональщини, імперативщини (навіть з try/catch) тощо.
Ось вам приклад

Pl/SQL, PL/pgSQL, T-SQL теж вже не зовсім той SQL.

і знову — тренд розвивати мову сервера БД з QL до універсальної — зрозумілий. та — давній.

Та ніхто ж не сперечається :)

Так, ще й які.
і які окрім — х-як, х-як і продакшн не включаючи голову?

сотні серверів з БД? так, може бути. цікаво тільки — а ті що жадають NoSQL — хоча б в одному такому проекті приймали участь?

Але треба ретельно вивчати інструмент і міняти мислення
зазвичай балакина про «міняти мислення» — нічого не варта. бо за нею стоїть не змінене мислення, а невігластво або інфантилизм. Нічого особистого.
Але треба ретельно вивчати інструмент
ну то тім що пхають NoSQL усюди — і тра накінець вивчити роботу з RD.

пхаюти NoSQL усюди — це називати ці решення — альтернативою.
а NoSQL на ділі- НЕ альтернатива RD, а рішення для вузьких, нетипових для RD задач. Коли немає потреби в функціоналі RD, а тра — просто в якусь купу звалити різнорідну інформацію. або інформація і операції над нею — прості.

Але ж звісно, то не цікаво, читати оті книжки.
Цікавише — «х-як, х-як і продакшн!».

Наприклад MongoDB — добра коли треба централізовано тримати логі. Проектувати структуру RDMS під це — не вгадаєш. сьогодні була одна, завтра додали деталізації, а післязавтра — видалили з БД логі старіші за 3 місяци. то нашо було витрачати час на проектування?
От тут я за Монгу.

Коли людина із «SQL головного мозку»
так так, це улюблений аргумент інфантів
ООП головного мозку, Windows головного мозку, і т.і.

а як просиш показати оте «змінене мислення, вільне від стереотипів» — то й почуеєш у відповідь якись наївні думки.

Проектувати структуру RDMS під це — не вгадаєш
А от зараз було смішно.
ак так, це улюблений аргумент інфантівООП головного мозку, Windows головного мозку, і т.і.
Ви не зрозуміли основного посилу. Давайте повторю іншими словами. Програмісти звикають до певних патернів, які вони використовують щодня протягом останніх надцяти років. Вони звикають до них настільки, що будь-яку іншу задачу вони намагаються вирішити у звичний спосіб. А інколи цей підхід не працює, особливо коли змінено базис. Будь-які намагання працювати з NoSQL рішенням як із звичною RDMS завжди призводять до відомого поганого результату.
Ви не зрозуміли основного посилу.
ви теж :)
Будь-які намагання працювати з NoSQL рішенням як із звичайною RDMS
а так і буде, коли самі данні та потреби їх обробки:

1. мають реляційну природу.
2. треба уникнути дублювання інформації.

це НЕ патерн програміста вимушує на NoSQL емулювати RDMS, а — данні та алгоритми їх обробкі.

ви хоч з нуля пишіть свою БД — якщо є п1 и п2 — то у підсумку ви матимите RDMS!

1. мають реляційну природу.
Це яку? Можна детальніше (я запитую, бо в багатьох є розбіжності в термінології)
2. треба уникнути дублювання інформації.
Це вимога логічного рівня, фізично можна зберігати інформацію як завгодно.
а — данні та алгоритми їх обробкі.
Дані зазвичай формуються в тому вигляді, який зручно обробляти певним інструментом. Якщо це RDBMS, то це будуть таблички, якщо це XMLDB, то це будуть XML-документи, якщо беремо файлову систему, то це будуть файли або файлові дескриптори. Якщо в нас KVS, то все буде тупим key-value. Про алгоритми теж все набагато простіше. Якщо ви обробляєте потік бінарних даних, то вже неважливо, з якого джерела були отримані ці дані, хоч з бази даних, хоч з файла, хоч з генератора випадкових чисел. Алгоритм залишиться незмінним. Обв’язка буде тільки різною.
Це яку? Можна детальніше (я запитую, бо в багатьох є розбіжності в термінології)
на хлопських прикладах, тлумачення терміну є в інтернетах.

головна — відношення тотожністі.

коли Вася в одному документі це той же Вася що й у другому.
але не той Вася що в третьому. то — інший Вася.

друга член множинності:
перший Вася входить до групи робітників, а от другий — до групи менеджерів.

Це вимога логічного рівня, фізично можна зберігати інформацію як завгодно.
так. зберігати купу можно як завгодно.
а от коли треба в ній знайти щось — то виявляєця що засіб збереження впливає на час пошуку.
Дані зазвичай формуються в тому вигляді, який зручно обробляти певним інструментом.
нє-а.

Дані зазвичай формуються в тому вигляді — щоб можна були отримти їх потім у зручному вигляді.

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

Якщо в нас KVS, то все буде тупим key-value.
якщо нам треба вибирати данні по критеріям для value — то тупим буде той що вибере для цього KVS, (бо це ж NoSQL!), і напише свій relation engine на клієнті.
Про алгоритми теж все набагато простіше.
та ну :)
Алгоритм залишиться незмінним
писав я той же обхід дерев і на MUMPS(бо там іншого і нема, там тільки- «дерева» — глобали habrahabr.ru/post/175659 , и на xpath (xDB developer-content.emc.com/...ocs/overview-summary.html

так що можу порівняти з SQL.
а, ще на dBase писав.

тому питаннячко ріторичне — алгорітм то незмінний — а код — теж буде незмінним?

особливо коли парадігми мов обробки даних — різні.

в інеті можна знайти порівняння коду одних і тих самих алгорітмів на SQL і на js для MongoDB.

NewSQL рулит — github.com/pingcap/tidb .

Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен.

Нужно было поместить эту фразу в начало статьи — сразу стало бы понятно, что читать её не стоило.

Именно, коллега.
Всё зависит от прямоты рук, а не от БД.

Печально, конечно, что в MySQL не все хорошо. Но это значит проблемы конкретно в MySQL, а не

Реляционные базы рулят
, логично?
Тогда и статью надо было бы назвать NoSQL vs MySQL и бла-бла-бла.

Статья называется «NoSQL vs SQL» а не «MySQL vs MsSQL»

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

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

от четверти до половины рынка баз данных
?
Market share показывает Оракл на первом месте, MySQL на втором, MS SQL на третьем.
То есть подход такой. Находим какую-то проблему в одной СУБД, и обобщаем эту проблему на все остальные СУБД этого класса?))
А можете показать ссылкой вот это
Наберите в гугле «MySQL market share» и ткните «Images», полистайте. Разные источники дают разные данные. Если еще отфильтровать коммерческие БД, то у MySQL явно будет большая часть рынка.
То есть подход такой. Находим какую-то проблему в одной СУБД, и обобщаем эту проблему на все остальные СУБД этого класса?))
Если эта одна СУБД имеет такой большой market share — то да. Особенно учитывая, что это один из немногих достойных опенсорцных вариантов на рынке.
Если еще отфильтровать коммерческие БД
был уверен, что таблицы с миллиардами записей будут на том, что «тянет» такую нагрузку, а не на том, что стоит дешевле :-/

Чем принципиально таблица с тысячей записей отличается от таблицы с миллиардом записей? Достаточно ли этого чтоб оправдать трату многих тысяч долларов на ПО?

Та Вас прям не понять. То когда я делаю тест на миллионе записей, пишете:

У моего друга было столько же строк, только в 4000 раз больше.
А когда я показываю тест на 100000000 записей с таким же результатом на Оракле (т.е. 0.2 секунды), уже не пишете.

То пишете:

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

А сейчас пишете:

Чем принципиально таблица с тысячей записей отличается от таблицы с миллиардом записей? Достаточно ли этого чтоб оправдать трату многих тысяч долларов на ПО?
Непонятно...

Ну вот, к примеру, www.scriptol.com/programming/mysql.php
20-30%, может быть, но не 50.
Достойный вариант — PostgreSQL, если уж на то пошло.

Автору статьи большой респект. Прочёл с огромным интересом. Не все умеют просто и прозрачно писать о совсем тривиальных концепциях. Такое чтение экономит часы, потраченные на документации, самостоятельные поиски и эксперименты. Знакомство с любой новой темой лучше всего начинать с хорошей статьи в стиле «в двух словах о главном».

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

Звісно що хохли усі
Полюбляють дуже Сі
Але якщо ти є москаль -
Використовуеш Паскаль

Искренне желаю автору научиться меньше обращать внимания на тех, кто ищет не понимания, но правоты. Как по мне, на их придирки едва ли стоит тратить время. А тем боле опускаться до личностей. Спасибо, Наталья, с нетерпением жду следующих статей. Те, кто идёт по пути знаний Вам благодарны. :)

"

о совсем тривиальных концепциях
" — имелось ввиду конечно же "
о не совсем тривиальных концепциях
" Сорри.

>

Звісно що хохли усі...

У Московії москаль
Дуже любить свій Паскаль -
В Україні геть усі
Програмуємо на С!

Хороша спроба, але ні.

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

Можно только согласиться с

— относиться серьезно к неявной схеме данных еще на моменте ее проектирования;
— покрывать тестами вашу неявнойсхему данных в базе, проверяя все нужные форматы содержимого

В комментариях у автора на фейсбуке начался такой фейспалм, что тут вывод один — автор упрт.
Извините, но как оценивать поток оскорблений в сторону людей, которые хотят помочь, предлагают свою помощь, но в ответ получают такое обвинения в пустозвонстве и балабольстве?
«Интересующихся» отсылаю почитать фейсбук автора, ссылку уже давали.

Я туда даже не заглядываю. Ко мне в ФБ прибежало, я так понимаю из клаки, и начало хамить и материться. Автор же просила меня ее забанить угрожая тоже антисоциальным поведением в моем ФБ :). Жесть. Бекграунд чек в соцсетях при найме полезная штука...

Вынесу отдельным постом добавочку на


Vitaliy Marenkov:
вау-эффект от noSQL давно прошел, большинство уже ее распробовали

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

Так как БД им менять не давали, то они на Мускуле соорудили Монгу!

красиво так, каталоги в xml хранят. гибкие средства добавлять атрибуты. завязка на UI. пользователь кликом может добавлять в UI доп атрибуты к узлу, с полем ввода.
фабрики моделей распознающие тип узла, и выдающие правильную модель.
на них навешаны презентеры с гридами.
со скоростью постоянного парсинга тоже круто поступили — завели таблиц индексирующих.
в которых и узлы дерева указаны.
с такими вот полями
node_id varchar(60)
node_ids varchar(60)
data varchar(255)
tree int(11)
lft int(11)
rgt int(11)
depth int(11)

красота!

вот только, случилась классика, как описано в упомянутой статье
«Почему вы никогда не должны использовать MongoDB»
После трех месяцев в разработке все прекрасно работало.
Но однажды в понедельник на планерке клиент сказал, что один из инвесторов хочет ... по компонентам изделия подбирать аналоги. компоненты знамо — на надцатом уровне дерева текстом записаны в xml

делов то!
вытянуть их в индексирующие таблицы, дописать в десяток классов обновление-чтение, и вуаля, «Монга» рулит!

И чем закончилась история?

Ага, ясно. А в чем смысл структуру каталогов в XML хранить?

как я понял, не имея доступа к телу папередников — им schemы-less очень захотелось.
и наваяли некий монгоподобный толи API, толи ORM, толи замахнулись на «1С» подобие.
но приключилось столкновение архитектурной астронавтики и всей с суровой действительностью.

Ясно, спасибо. Таких извращенцев везде много. У нас тут похожая шняга в одном из приложений. ORM плюс сериализация состояний объектов в таблицы, плюс сообщения, очереди сообщений (куда ж без них), нагрузка в виде XML, которая раньше целиком писалась в базу, но теперь хотя бы уже есть разбор и запись в таблицы, и конечно хайбернейт — куда ж без него. Оракл в качестве базы, правда.

Продолжение...
Вобщем решили переписать практически с нуля.
Заказчик понял аргументацию почему при существующем подходе каждая фича будет занимать в 3 раза больше времени чем при классическом.
Вот только кажется он не понял, что такое «переписать с нуля» подсистему на специфику которой завязана бизнес-логика, и ожидает что фичи станут делаться уже на третий день.

Ну это обычное дело конечно, постройте мне второй этаж вначале, а фундамент и первый этаж потом как-нибудь.
«Мне нужен результат!».

А с реальной монгой как-то сталкивался. Через Doctrine. И нет особой разницы что там ща сервер бд 😁

Ну поздравляю, че! Или сочувствую. Из папередников хоть кто-то остался чтобы быть гидом в дебрях кода, который наваляли на основе той чудо-концепции?

В том и дело, и один из главных аргументов и был
Ни проектной доки, ни коментариев в коде нет. А доступ к паперелникам сам заказчик обрубил, разругавшись с ними в хлам.
Хотя, в коде, как видно по его подслоям, последнем встречаются комментарии в стиле:
Эта хня уже точно не нужна, но непонятно где ее могут вызвать поэтому замокапил, а не удалил.

Но чаще короткие
Код пахнет дерьмом, переписать! Потом.

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

Да, надо уточнить

У меня есть хороший опыт работы с деревянной бд — MUMPS, и небольшой с xml бд от EMC (там вместо SQL xpath), и поэтому уверен что папередники черпали вдохновение с монги. Общее у всех трех — ским лесс.

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

Спасибо за статью, надеюсь на продолжение.
Комментарии удивляют. Мне кажется очевидным, что статья намеренно упрощена, чтобы дать общее понимание широкой аудитории, с самого начала написано «мы рассмотрим существующие NoSQL технологии, их особенности и отличия от классических реляционных SQL баз». Ну и к противопоставлению тоже прицепились как-то зря. В общем, Наталья, надеюсь, эти комментарии вас не отвадят от написания продолжения )

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

Думаю, и среди технических специалистов есть люди без глубоких знаний СУБД, но интересующиеся. И такая статья как раз будет хорошим началом, вон там и ссылка на книжку есть.
Что касается искажений, то из комментариев, которые я прочла (не все, конечно), сложилось впечатление, что основные претензии к тому что автор для упрощения видоизменяет терминологию (лично я не вижу большой проблемы в том чтобы говорить не «реляционная», а SQL, хотя это формально и неправильно), а также в том, что «и в реляционных СУБД так можно» (опять же, у меня не сложилось впечатления, что статья это агитация за NoSQL).

Мда. К сожалению, я один из этих «интересующихся». Вторая статья на тему NoSQL на ДОУ — и вторая получает пометку «шлак». Как минимум благодаря трешу в сторону реляционных БД. Эххх, жалость-то какая

Интересующимся во всех случаях лучше рекомендовать документацию по конкретной СУБД, это существенно уменьшает риск возникновения разных домыслов и прочих городских легенд.
Либо же рекомендовать проверять самому на основе каких-то подготовленных тестов. Или опираться на факты, подкрепленные тестами. Если же описывать какую-то проблему в контексте сравнения, то должна быть четкая постановка конкретной проблемы и способы ее решения. Это ведь называется инженерным подходом, нет? А не

Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен

А что такого уж прямо невозможного в ситуации, когда ALTER TABLE занимает 8.5 часов? Вполне рядовая, на мой взгляд проблема на больших базах? В чём нечёткость постановки проблемы?

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

Вам приходилось когда-нибудь сталкиваться в реальной работе с таблицами в которых уже находится хотя бы несколько миллионов записей? А несколько сотен миллионов? Что значит «сервер недоступен? Во время выполнения DDL-транзакции, DML-транзакция, пытающаяся прочесть данные из модифицируемой таблицы, будет попросту ждать, пока первая не закончится, либо пока не истечёт таймаут. Т.е. данные из данной конкретной таблицы будут недоступны. Данные из других, не связанных с ней таблиц могут быть доступны (всё зависит от того, как написаны запросы), но время доступа вырастет в десятки, а может и сотни раз. Если на БД, обслуживающей тысячи (или более) клиентов, нужно провести изменения структур данных, всеприложения имеющие доступ к БД обычно останавливают, а потом перезапускают. Это общепринятая практика. Вот что имеется ввиду под фразой «сервер базы данных недоступен». :)

Если человек делает для модификации такой таблицы ALTER TABLE, вместо общепринятых методов, описанных в комментах, то он просто идиот.

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

Давайте сразу определимся с терминологией. DDL, DML ортогональны понятию транзакция. Для Вас сразу вопрос — с чего начинается транзакция вообще и в какой момент начинается транзакция для оператора DDL? Теперь продолжим по тексту.
Итак, не во всех СУБД она недоступна для чтения, иными словами в процессе работы «Alter table» возможно чтение этой таблицы из других сессий.

Данные из других, не связанных с ней таблиц могут быть доступны (всё зависит от того, как написаны запросы), но время доступа вырастет в десятки, а может и сотни раз
Можете прояснить что это значит? Я не понял. Что значит, время доступа вырастет в десятки-сотни раз?
Если на БД, обслуживающей тысячи (или более) клиентов, нужно провести изменения структур данных
Вернемся к вопросу. Какие конкретно операции «Alter table» могут занимать такое длительное время?
Вам приходилось когда-нибудь сталкиваться в реальной работе с таблицами в которых уже находится хотя бы несколько миллионов записей? А несколько сотен миллионов?
Я могу создать таблицу в «несколько миллионов» записей, на которых любые операции «Alter table» будут почти мгновенными, что на это скажете?
DDL, DML ортогональны понятию транзакция.
Простите, вот тут я не понял, кто на ком стоял, простите? ;)
Я не понял. Что значит, время доступа вырастет в десятки-сотни раз?
Вам когда-нибудь приходилось писать/читать большие файлы на/с диск(а), который в данный момент дефрагментируется? Примерно такой же эффект.
Какие конкретно операции «Alter table» могут занимать такое длительное время?
Например расширения колонки. Даже на несколько символов. Если таблица достаточно большая, эта операция может занимать часы.
По последнему пункту. Если Ваша цель доказать, что вы круче всех, можете считать, что Вы её уже достигли. :) Мне это не интересно. Хотелось бы понять не уровень Вашей крутизны, а в чём конкретно Ваши претензии к автору статьи. ;) А разгадывать шарады мне не скучно, извините.

40 млн? А как думаете, сколько новых записей в индексах Google появляется ежедневно? Ну, хоть приблизительно, можете объем оценить, навскидку, плюс-минус миллиард хотя бы?

Смысл ответа в том, что бывают случаи, когда ни одна из известных в мире реляционных БД ни на одном из изветсных в мире аппаратных решений просто не может справиться с необходимой нагрузкой. А кастомное NoSQL решение справляется (Гуглем все пользуемся). Странно, что такие вроде бы очевидные вещи приходится объяснять людям, любящим порассуждать о чужой компетенции. ;)

Денис, Вы пытаетесь доказать мне, что не бывает в природе случаев, когда DDL-statement может выполняться на базе часами? Вы какого примера хотите? Хотите чтобы я Вам базу живую выкатил и запрос написал, который займёт 8.5 часов? Извините, у меня несколько нескромный вопрос: а какой бюджет у этого проекта?

Хотите чтобы я Вам базу живую выкатил и запрос написал, который займёт 8.5 часов?
DO SLEEP(30600);
 я так полагаю?

Пока нет ответа на вопрос о бюджете проекта, разговор не имеет большого смысла. ;)

Какой бюджет? Пишите тест кейс, я выполню его на одной из баз, куда у меня есть доступ. Абсолютно бесплатно!

Бесплатное кодирование в воздухе — это для голодных студентов. Не по адресу предложение. ;) Если Вам удобно считать, что долго выполняющиеся DDL — это фантастика — воля Ваша. Мне как-то пофигу.

Если Вам удобно считать, что долго выполняющиеся DDL — это фантастика — воля Ваша. Мне как-то пофигу.
Вообще-то речь шла о конкретной разновидности оператора DDL — Alter table.
И пока что Вы генерировали высказывания, мягко говоря, неверные, а по сути — бредовые.
Во время выполнения DDL-транзакции, DML-транзакция, пытающаяся прочесть данные из модифицируемой таблицы, будет попросту ждать, пока первая не закончится, либо пока не истечёт таймаут.
Это неправда для Оракла, в частности и блокировочников, в целом.
Например расширения колонки. Даже на несколько символов. Если таблица достаточно большая, эта операция может занимать часы.
Это тоже брехня, я это показывал.
Но могу еще раз показать вместе со сменой значения по умолчанию и апдейтом столбца.
SQL> create table t1 (n1 varchar2(4) default 'TEST' NOT NULL);

Table created.

Elapsed: 00:00:00.02
SQL> insert /*+ append */ into t1 select 'test' from dual connect by rownum<1000
000;

999999 rows created.

Elapsed: 00:00:00.72
SQL> commit;

Commit complete.

Elapsed: 00:00:00.02
SQL> alter table t1 modify (n1 varchar2(12) default 'POST');

Table altered.

Elapsed: 00:00:00.03
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00
SQL> update t1 set n1='TESTTESTTEST';

999999 rows updated.

Elapsed: 00:01:00.36
SQL> commit;

Commit complete.
Обновление миллиона строк — минута. Это простой тестовый сервер на виртуалке, ничего такого.
По идее, уже сейчас должно быть примерно понятно, какая разновидность alter table и в каком же случае может зависнуть, не?
Хм... Добавить новую колонку новой длины (не могу сказать про мускл, но у майкрософта эта операция даже для «нот нулл» сейчас выполняется очень быстро). Вот прямо сейчас запустил тест — на таблице в 40+ млн строк она добавилась за 0.2 секунды.
Я дочь DBA, только из силиконовой долины, тут не все так однозначно.

На моей прошлой работе у одного моего знакомого была mysql база, по размерам приближающаяся к 5 ТБ.

Добавление пустого null столбца занимало больше часа, и втечение этого времени база то ли была полностью недоступна, то ли перформанс падал до нуля. Единственный способ добавить столбец был — несколько недель ждать, пока появилось окно, в котором такой простой привел бы к минимальному ущербу для бизнеса. Реляционные базы рулят.

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

Вот именно что хитрый.

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

(ну, и другие тоже упоминали, но меня скорее удивляет, что вы сначала приводите решение проблемы, а позже пишете насчет сложности этой же проблемы)
Что именно вас удивляет? ALTER TABLE может привести к даунтайму на несколько часов, и эта проблема никуда не пропала.

Предложение запилить свой transaction log поверх существующего функционала БД для того, чтоб добавить столбец, оставлю без комментариев.

для любой технологии можно подобрать кейс где она булет тупить.

База в 5тб с доступом 24/7 — редкий случай. И то, меньше двух часов говорите добавляется колонка? Для 5ти тб это круто, имхо.

Обычный же кейс:
База в сотни гиг, и в течении недели есть возможность ее остановить на 12 часов для регламентных работ.

Еще интересный вопрос как поведет себя монга с базой в 5тб когда понадобится значение заменить ссылкой.

Еще интересный вопрос как поведет себя монга с базой в 5тб когда понадобится значение заменить ссылкой.
Ну поинт в том, что монга ничего не знает о схеме. Когда надо что-то поменять, написал код, запустил его с низким TPS когда нагрузка поменьше, и ждешь пока вся база не проапдейтится. Можно хоть неделю ждать, импакта на сервис никаокго.

да, есть такое.

Вот кстати и можно взять за критерий выбор бд
как часто будет меняться структура бд? (А если для неструктурированных и разреженных данных применяется EAV? Или если хранение в json мускулом 5.7, постгресом, ...)

Конечно в дополнение к остальным.

Сочувствую горю вашего знакомого.

08:48:27 SQL> alter table t1 add (location varchar2(256));

Table altered.

Elapsed: 00:00:00.09
08:48:39 SQL> select count(*) from t1;

  COUNT(*)
----------
    999999

Elapsed: 00:00:00.12
SQL> alter table t1 add (location3 varchar2(256) default 'unkown' not null);

Table altered.

Elapsed: 00:00:00.01
SQL>
Реляционные базы рулят.
Хотели сказать, MySQL базы рулят?)
COUNT(*)
----------
999999
У моего друга было столько же строк, только в 4000 раз больше.

т.е. 4 миллиарда в одной таблице? А средний размер строки какой был, может тоже знаете? Но окей, я чуть позже сделаю.

Окей, так пойдет? Не хочется добавлять кучу датафайлов ради бессмысленного эксперимента.

SQL> alter table t1 add (location varchar2(256));

Table altered.

SQL> set timing on
SQL> alter table t1 add (location3 varchar2(256) default 'unkown' not null);

Table altered.

Elapsed: 00:00:00.02
SQL> select count(*) from t1;

  COUNT(*)
----------
 100000000

Elapsed: 00:00:10.56

Могли бы написать просто «она плохая». Смысл тот же, но гораздо меньше слов. ;)

Спасибо. Поржал. Вопрос был задан не вам. Но Ваш вариант ответа меня повеселил. Так что я Вам благодарен.

Мне Вас жаль, Денис. Вы забавный, но цели Ваши в данный момент ничтожны. :) Мне скучно с Вами беседовать, сорри.

вот я щас прям представил как бедняга Джоэль Спольски запускает ALTER TABLE и stackoverflow отключается на 8 часов.
сервер не доступен, миллионы программистов простаивают, сисадмины не могут поднять упавшие сервера, в мире творится хаос и паника.
Джефф Этвуд, пиная серверную стойку, кричит «Джо, какого черта?! Почему мы не выбрали mongodb?»

Всё верно, в том и проблема, что после того, как БД уже стоит в продакшне, такие простои просто недопустимы. Если такая необходимость возникает, её приходится обходить теми или иными техническими или организационными средствами. Нужно ли говорить, что это не всегда дёшево и не всегда удобно?

c надуманными трудностями сталкиваются только те, кто их выдумал)

зато контролировать целостность данных в нереляционных субд просто и дешево. нет целостности — нет проблем.

ну и что, что кодер Вася пришел с перепоя и дата теперь в половине документов как int(20161118), а в другой половине как string(6) «20161118» (ох уж эти языки со слабой типизацией).
и подумаешь, что нужно писать кучу дополнительных прослоек. это же так просто.

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

Простите, вот тут я не понял, кто на ком стоял, простите? ;)
Плохо, очень плохо. Это же азы вроде бы, не? Транзакция в разных СУБД начинается по-разному, но основной смысл транзакции — это изменение состояния базы данных. В Оракле транзакция неявно начинается первым оператором, изменяющим данные. Запрос Select (если нет каких-то внутренних вызовов) данные не изменяет и транзакцию не начинает в общепринятом смысле. Согласованность данных обеспечивается по-разному в разных СУБД опять же, но для одиночных запросов обычно гарантируется и подразумевается согласованность данных на уровне оператора. За подробностями я лучше отошлю к литературе) В версионных СУБД нет блокирования читающими пишущих и наоборот. Т.е. «ALTER TABLE» НЕ БЛОКИРУЕТ запросы на чтение из других сессий, так понятно? DDL состоит минимум из двух транзакций, так как в самом начале выполняется неявный коммит, и дальше идет сама операция, которая может состоять из обновлений словаря данных и каких-то изменений в таблице.
Вам когда-нибудь приходилось писать/читать большие файлы на/с диск(а), который в данный момент дефрагментируется? Примерно такой же эффект.
СУБД не файловая система, здесь эффекты вообще другие.
Например расширения колонки. Даже на несколько символов. Если таблица достаточно большая, эта операция может занимать часы.
SQL> create table t1 (n1 varchar2(4));

Table created.
SQL> insert /*+ append */ into t1 select 'test' from dual connect by rownum<1000
000;

999999 rows created.

Elapsed: 00:00:01.53
SQL> commit;

Commit complete.
SQL> alter table t1 modify (n1 varchar2(12));

Table altered.

Elapsed: 00:00:00.24
SQL>
Еще предложения?
Хотелось бы понять не уровень Вашей крутизны, а в чём конкретно Ваши претензии к автору статьи. ;)
Претензии точно такие же как и к Вам, к примеру.
Прежде чем писать ахинею, надо либо почитать документацию, либо проверить эту ахинею собственными руками.
Прежде чем писать ахинею, надо либо почитать документацию, либо проверить эту ахинею собственными руками.
боже упаси, с кем мы спорить будем тогда?

Простите, запамятовал, а кто из присутствующих обвинял в грубости и некомпетентности автора статьи? :) Если интересует мой опыт работы с БД, велкам ту май Линкдин профайл. ;)

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

Простите, запамятовал, а кто из присутствующих обвинял в грубости и некомпетентности автора статьи?
из присутствующих? хм, дайте посчитаю — все кроме вас.

Я могу поставить вопрос иначе. Откуда у Вас лично сведения, что я не читал документации Oracle? Только ответьте уж пожалуйста на мой вопрос прямо, как Вы любите. Чтоб мне было легко связать Ваш ответ с моим вопросом. ;)

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

а претензии к автору вполне обоснованы. она несет чушь. мало того это не конкурентные технологии, чтоб их так просто сравнивать — есть места, где использовать NoSQL субд худая затея. а есть места, где использовать реляционные субд не лучший выбор.
и вот поэтому к автору так плохо отнеслись — к содержимому статьи отлично подходит заголовок «почему SQL» должен умереть.
у вас была возможность потрогать оракл, mysql, mssql и монгу, например, и исходя из опыта вы можете определить (ну по крайней мере я надеюсь, что можете) что следует использовать в каком случае. у кого-то, например, такого опыта нет. человек прочтет статью, вобьет себе в голову мысть, что sql говно и должно умереть, а в результате начнет городить прослойки для NoSQL субд, которые благодаря которым она начнет смахивать на реляционные. ну внешне. или, как я писал выше, заказчик прочтет эту статью и скажет — а я вот хочу чтоб это было на CouchDB. потому что так модно щас.

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

А между тем, автор статьи в отличии от некоторых обвинителей знает и разницу между пишущей и читающей транзакцией, и даже слышала о том, о различных стратегиях поддержания целостности в реляционных СУБД.
тоже в общем-то спорный момент.
Сердечно благодарю Славу Конашкова за технические консультации и помощь в написании материала.
Вместо профессиональной дискуссии и выяснения тонкостей, устроили форменный срачЪ (ТМ)
все развлекаются как могут :D.

авторам статей нравится писать статьи. злобным комментаторам нравится злобно комментировать.

все получают удовольствие (или по крайней мере развлечение), а Наталье просто стоит не брать все это близко к сердцу и делать покерфейс вместо «затыкания глоток ревнителей».
тоже в общем-то спорный момент
Кому как. Я с автором статьи не только в комментах на ДОУ общаюсь.

Что касается развлечений, меня, если честно развлекаторы чуточку заразвлекали уже. Вместо профессиональной дискуссии какой-то сплошной срачЪ под девизом «кто круче почешет своё ЧСВ». :)

от этого никуда не деться, такое и на хабре есть и на профессиональных форумах.

кто круче почешет своё ЧСВ
а я просто наслаждаюсь срачем:D

Прошу вибачення, або я тупий, або в мене вже професійна деформація. Яка може бути транзакція при читанні? Ви де таке бачили? Може ви щось інше транзакцією називаєте?

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

Я про транзакції питав, а не про особливості реалізації та термінології в певних програмних продуктах. ;)

При читанні має зберігатись узгодженість чи можна читати все що бачиш?)

Може. Ось тут наприклад: docs.oracle.com/...ents_10005.htm#SQLRF01705 Шукайте «READ ONLY»

Read-only transactions are useful for reports that run multiple queries against one or more tables while other users update these same tables.
Отже, можна зробити резюме, що ці транзакції — фікс випадків, коли дані читаються декількома запитами, а не одним, що б дозволило використовувати без проблем механізм версійності.

В цьому конкретному випадку — так. Але, в інших випадках може бути інакше. Наприклад в MS SQL (не версійник, а блокувальник) читаюча транзакція може навіть блокувати пишучу транзакцію, яка намагається змінита дані, яки вона зараз читае. Або навіть дані, які зберігаються фізично «близько» до тих даних, які читаються. Така ситуація може викликати deadlock. Я не впевнений що знаю всі можливі випадки я мав справу безпосередньо тільки із MS SQL та Oracle. Всі інші — в найкращому разі тільки трохи грався.

Вместо профессиональной дискуссии и выяснения тонкостей
Так это, может расскажете
о различных стратегиях поддержания целостности в реляционных СУБД
?
Или имелась в виду не целостность, а согласованность?)
А если таки целостность, то какие таки есть стратегии?)

Бросил читать с того момента, где select в Оракле не начинает транзакцию. Может Вы ещё объясните мне разницу между блокировочником и версионником? Попробуйте, это может быть забавно было бы почитать. :)

)

SQL> commit;

Commit complete.

SQL> select * from dual;

D
-
X

SQL> SELECT dbms_transaction.local_transaction_id FROM dual;

LOCAL_TRANSACTION_ID
-------------------------------------------------------------



SQL> select n1 from t1 where rownum<2 for update ;

N1
------------
test

SQL> SELECT dbms_transaction.local_transaction_id FROM dual;

LOCAL_TRANSACTION_ID
-------------------------------------------------------------

6.2.17694

SQL> commit;

Commit complete.
Ой, что это?)
Конечно, любой запрос меняет SCN, так как для запроса важно получить от системы snapshot SCN, т.е. момент времени, на который данные будут согласованы. И по сути, есть неявные вызовы, которые устанавливают уровень изоляции транзакции или делают системные вызовы для получения новых SCN, и неявно транзакция есть, но формально ее нет.
Разница между блокировочником и версионником очень проста — способ, которым обеспечивается согласованность. Версионники создают версии изменяемых данных, что позволяет не блокировать данные при чтении, в частности. Оракл — своего рода гибрид, так как по сути, анду или роллбек используется для хранения предыдущих версий, что не совсем соответствует концепции версионников, ну и плюс для версионников очистка старых (версий) данных — это проблемный момент.
Так Вы созрели уже назвать тот самый «Alter table», который может занимать много-много часов или пока нет?) Давайте, переберем все варианты, чего там!

С Вами крайне скучно спорить, уважаемый. Вы очень плохо знаете предмет и слишком многого хотите от собеседника. :) Будьте здоровы, знаток Оракла. ;)

Очень жаль, что так и не удалось прочесть у Вас хоть какие-то аргументы)

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

Причем тут кванторы?)
Заметьте, я обращаю внимание на некорректные формулировки у Вас, представляю аргументы со своей стороны, в ответ я слышу какие-то отмазки типа

Вы очень плохо знаете предмет и слишком многого хотите от собеседника.
Покажите в чем я не прав, это же просто?)
Можете объяснить, например, отсутствие записи в v$transaction в случае одиночных селектов в сессии?)
Или почему после селектов все еще возможно поменять уровень изолированности транзакции?)

Когда в ответ на вопрос, таким уж невозможным выглядит выполнение DDL в течение 8.5, человек приводит DDL, который выполняется быстрее — у него явно поблемы с кванторами. Когда-то были времена, когда люди считали Землю плоской. И доказать, что она имела форму шара было не то чтобы сложно, а почти невозможно. И тем не менее, тогда она имела ту же форму, что и сейчас. Обсуждать особенности работы БД Oracle мне не интересно. Статья не об этом. А в то, что я могу от Вас узнать что-то новое об Оракл мне не очень верится.

OMG, да у Вас ЧСВ еще круче чем у автора!
Чтобы закрыть уже эту тему с «DDL». Единственный вариант оператора alter table, который может выполняться долго (насколько я знаю), это alter table drop column. Констрейнты я не рассматриваю, так как всегда есть возможность отложенной валидации для них. Для того чтобы alter table drop column выполнялся 8 часов, таблица должна быть размером 2 терабайта (примерно). Естественно, запуск подобной команды на такой таблице равноценен пословице «заставь дурака богу молиться».
Но это пол-проблемы. Основная проблема для подобной операции — это количество анду и реду (для Оракла) или просто количество журнальной информации (для других СУБД). Опять же, в Оракле если удаляется больше чем один столбец, то количество анду добавляется для каждого удаляемого столбца. Это уже реальная проблема, так как если не следить, то где-то на пути эта операция может упасть с ошибкой, и тогда нужно либо перезапускать удаление, либо еще что-то думать. Но есть и нормальные способы справляться с проблемой. Столбец можно сделать «неиспользуемым» или «невидимым» вместо этого. Можно переименовать и добавить новый, если необходим тот же столбец. В крайнем случае, можно реорганизовать таблицу, тем более если таблица секционирована (а на таких размерах это практически требование), это можно делать посекционно. В любом случае есть масса подходов, про которые тут уже не раз писали.
Пример я приводил в ответ на Вашу реплику, напомню еще раз

Например расширения колонки. Даже на несколько символов. Если таблица достаточно большая, эта операция может занимать часы.
Ну уже разобрались же, что чепуха?
А в то, что я могу от Вас узнать что-то новое об Оракл мне не очень верится.
Очень жаль) Я вот надеялся что смогу узнать от Вас что-то новое, но видно, не судьба)
Я всегда готов узнать что-то новое, тем более что последнее время не так часто использую Оракл, только когда возникает «нагальна потреба». Я хоть и OCM, но стараюсь по мере возможности изучать что-то новое и не отставать от новинок. Статья могла стать сравнением в контексте реальных проблем, и в этом случае была бы хорошим «началом для интересующихся», но нет.

Денис, проблема не только в этом, это следствие. Объем знаний, необходимых для работы в любой сфере, трудно переоценить, но часто те люди, которые спустя Х или ХХ лет опыта, начинают думать что знают все, просто перестают учиться дальше. Там на фейсбуке автора дядя пишет следующее:

Alexander Levinson Почитал немножко срач в каментах. Трое-четверо самых активных комментаторов не произвели на меня впечатления слишком уж больших знатоков реляционных БД, имеющих опыт работы со сколько-нибудь большими объемами данных. :) Мне кажется, с ними вообще не стоило спорить. Уровень понимания проблем бизнеса, работающего с большими объемаи данных, и проблем производительности БД ничего кроме улыбки не вызывает.

Ну я лично мог бы пожертвовать временем и создать среднюю табличку, и даже не из одного столбца и с нормальным уже размером строки, но видимо, нет такой необходимости. А например, оценку времени для удаления столбца я экстраполировал исходя из того что у нас на 100Г таблице удаление шло 20 минут. И такая экстраполяция подтверждается, достаточно немного поискать в интернете или на металинке том же.

Ну это да. Там просто была ситуация когда надо было откатить часть апдейтов, в том числе и добавление столбца. Возвращать базу на момент начала всех апдейтов не было смысла, так как сами апдейты занимают по времени много. А поскольку на таблице индексы по размеру были в районе 500Г, то делать реорганизацию тоже не было смысла. Тем более, что разработчики четко знали, что они хотят откатить и накатить заново, так что то было вполне логичное и самое простое решение. Сколько займет по времени, самому было интересно.

Та це типова поведінка псевдогуру. Дути щоки, розпускати хвоста, робити загадковий вигляд, кидатися лайном в опонентів. Гуру завжди розмазує опонента тонким шаром своїми прикладами, знаннями, фактами, доказовою базою. Сімулякри ж такого зробити не можуть, бо їх самих можуть змішати із лайном...

Что меня более всего поражает в людях — так это уверенность в своём праве ставить кому угодно задачи и требовать от кого угодно ответов на свои вопросы. СрачЪ (ТМ) начался с того, что я спросил, на чём базируется уверенность в невозможности выполнения ALTER TABLE в течение 8.5 часов. Мне привели один или два частных случая, когда ограничения этой команды можно обойти за счёт знания тех или иных особенностей той или иной БД. ОК. Я принял это к сведению. Своё мнение об уровне претензий к автору статьи я уже составил. Более мне эта дискуссия не интересна. Свою правоту я никому доказывать не собираюсь. Вообще дискутировать имеет смысл в двух случаях: когда дискуссия интересна сама по себе, либо когда она является средством заработка. Тут имеет место третий случай. :)

Более мне эта дискуссия не интересна.
Вибачте що я тут зі своїм рилом в калашний ряд лізу, але навіщо ви взагалі ведете дискусію, яка вам, за вашими словами, не цікава? Щось показання не співпадають...
Свою правоту я никому доказывать не собираюсь
Зачекайте, ви ж хотіли вести професійну дискусію...
Вместо профессиональной дискуссии какой-то сплошной срачЪ под девизом «кто круче почешет своё ЧСВ».
Чи вже все? Професіонал, який хоче вести професійну дискусію, просто бере й веде її. Тоді він цікавим стає для інших. Тоді він може передати свої знання. Наприклад, цікавий факт із рід-онлі транзакціями пояснює деякі моменти в складності фіксування версії у випадку, коли скрипт має декілька селектів, які пов’язані між собою тільки на програмному рівні (pl) а не рівні sql. Ну цікаво ж! Набагато краще, ніж читати про
Мне всегда было лень спорить с людьми, не понимающими разницы между кванторами существования и общности. И поныне лень.

Ну я сталкивался. Сбор данных с датчиков, расположенных в трех областях, срез 2-секундный. Объем БД — пара терабайт. И что? Простейшие операции alter table проходят вполне себе леххко. Потому Вас и спрашивали — о каких конкретно операциях речь и о каких конкретно объемах.

А что за СУБД, если не секрет, и что используете для работы с временными рядами?

Oracle Standard Edition, по тем временам кластер на 2 узла был в комплекте.
Секрет успеха был в отключении по максимуму индексов, которые советовала логика.
Для работы с временными рядами использовалась SCADA. Но у нее логика работы тоже была простая — выбрать данные одним запросом по максимуму, а дальше уже ворочать этими данными для получения каких-то фильтраций, сортировок и проч на стороне веб сервера

Ага, интересно. Да, компания, которая предлагает это решение, судя по всему, американская.

Абсолютно нет. Харьковская. Чисто украинская. Решение просто узкоспециализированное. Там, вобщем-то, вариабельность небольшая :) Ну если не изобретать велосипед. Что очень дорого, очень долго и маловероятен успешный финал. Ну или бюджет будет сравним с ВВП какой-нибудь маленькой, но очень гордой республики :)

А, я подумал что SCADA — это конкретный продукт, и нагуглил некую компанию сразу.
В общем, я как бы работаю в компании, где как раз целая куча очень разных велосипедов в этой сфере. Так или иначе используются оракловые продукты, современные подходы и все такое. Велосипеды хоть и ужасные, но пока клиенты ездят на них, то все хорошо)

что такого уж прямо невозможного в ситуации, когда ALTER TABLE занимает 8.5 часов?
Спираючись на таку логіку, можна сказати, що чоловіки мають зріст 220 сантиметрів (коли насправді лише один з усіх моїх знайомих чоловіків має такий зріст).
Спираючись на таку логіку
Не зрозумів, про яку логіку йде мова?

А де ви побачили в моєму питанні бінарну логіку? Або взагалі будь-яку логіку. Питання — це просто питання. Логіка повинна бути у відповіді. ;)

Та це типова поведінка псевдогуру. Дути щоки, розпускати хвоста, робити загадковий вигляд, кидатися лайном в опонентів.
А про псевдогуру то теж був жарт, чи то було серйозно. Як взагалі зрозуміти де Ви жартуєте, а де Ви серйозний?

Смайліки! Завжи ставлю смайліки, де є натяки на жарти.

Угу... Тож там де про псевдогуру смайлика немає. То ж я так розумію, що там все було серйозно. ОК. Тоді я взагалі не розумію про що Ви. В питанні логики бути не може, то ж на роль гуру ніхто навіть не претендував. Бо гуру ж не той, хто задає питання, а той, хто дає відповіді, так? То ж до чого тут взагалі псевдогуру?

Скоріше за все, через обмеження двигуна DOU, ви втратили контекст відповіді. Там була зовсім інша ситуація.

Другой контекст? Какой же? Кого нужно было размазать тонким слоем? И главное — зачем?

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

Вот опять. Вроде и не спорил ни о чём. Только вопросы задавал. И снова оказался виноват. :) Не хотите отвечать — не нужно. А время Ваше я не тратил Вы сами влезли. Я к Вам даже не обращался. Так что потраченное Вами время — целиком и полностью на Вашей совести. ;)

А ветку я читал. Второй раз перечитывать не буду. Не настолько интересное чтение. :)

Обережно, дядя дуже нервується в ситуаціях коли може бути неправий і в дяді може статися нервовий зрив)

Зрозумів. Буду обережним

Йдеться про те, що авторка статті як один з аргументів проти реляційних баз даних наводить приклад: «Например, ALTER TABLE занимает 8,5 часов», коли зазвичай ця операція займає набагато менше часу. І коли цей аргумент критикують, то на його захист висувають тезу, що ця ситуація можлива. Аналогічно можна уявити, що монтажники повісили вішалки для одягу надто високо, аргументуючи це тим, що чоловіки мають зріст 220 см, а коли їм кажуть, що треба повісити нижче, бо не можна орієнтуватися на той зріст, вони відповідають: «А хіба не буває чоловіків зростом 220 см?».

:) Ну, поперше, я вважаю, що з контексту статті досить очевидно, що коли мова йде про «ALTER TABLE занимает 8,5 часов», йдеться саме про досить старі та досить великі БД. Тобто саме про можливість такого сценарію, а не про його ймовірність. «Зазвичай», між іншим, теж буває різний. Якщо йдеться про маленьку базу на десктопі девелопера, — це один «завзичай», якщо, наприклад, про продакшн базу де відбувається білінг великого TELCO оператора — це зовсім інший «зазвичай».

Що стосується «тез на захист», я взагалі не розумію, навіщо й кого тут потрібно захищати, а головне — від кого? Я взагалі не розумію, контексту «напад — захист» в професійних дискусіях. :) Якщо хтось вважає за потрібне нападати на мене, чи на авторку статті, тоді я взагалі не вважаю за потрібне з тією людиною дискутувати. Бо це вже не дискусія а срачЪ (TM).

йдеться саме про досить старі та досить великі БД
мова не лише про «досить спеціфічні умови», а і «придумаю собі обмеження та доведу, що реляційні БД — лайно». звичайна собі маніпуляція-перекручування
це вже не дискусія а срачЪ (TM)
що реляційні БД — лайно
Мені здається, це і є моментом істини. Справа в тому, що в тексті статті немае жодного навіть натяка на те, що з реляційними БД щось не так. Навпаки, йдеться про те, що для для своєї традиційної сфери використання, це дуже влучне рішення, яке «продолжает служить нам верой и правдой по сей день».

Це однак жодним чином не виключає існування недоліків цієї моделі, особливо враховуючи появу деяких нових вимог до БД. Якщо авторка перелічує деякі з цих недоліків, це не є доказом того, що вона вважає реляційні БД за лайно. Я впевнений, що це не так. То ж я й кажу, що більщість критиків (не всі, але більщість) дискутують із уявним опонентом. Навіщо вони це роблять? Я маю свою точку зору на це питання, але не вважаю за доцільне дискутувати з цього приводу. :)

кого тут потрібно захищати
Нікого.
контексту «напад — захист» в професійних дискусіях
 А ви саме в цьому контексті розглядаєте коментарі?
хтось вважає за потрібне нападати на мене, чи на авторку статті
Хтось нападає на вас чи на авторку статті?

Перемкніть контекст. Дискусія складається, зокрема, з аргументів, із критики аргументів і з захисту аргументів. Ніхто ні на кого не нападає.

Читайте трохи вище. Я там вже все пояснив. Те що стосуеться дискусій з уявним опонентом. То ж наскільи я можу судити, Ви саме з уявним опонентом дискутуєте. :) Це ж Ви почали говорити про «тези на захист». ;) Може це Вам потрібно перемкнути контекст? Бо саме Ваши аргументи жодним чином не стосуються статті. :)

Читайте трохи вище
Чого й вам бажаю.

Просто дядє хочеться думати що він робить роботу для якихось міфічних вєліканів)
Не треба руйнувати міфи)

По правде сказать — желания продолжать нет никакого. Я планировала написать ещё статьи, чтобы освятить темы «Агрегатные базы» и «Особенности семейств технологий NoSQL». Но может быть кто-то из подписавшихся под этим материалом знатаков сможет упртс так же как я и написать эти статьи вместо меня. С удовольствием почитаю.

Извините, Ольга, за мой едкий тон — просто мне очень противно читать всю эту мерзость о себе. Спасибо, что оценили мой труд.

Ниче не понял.

Только начал читать и на те.

Как всем нам известно, реляционная модель данных — это не что иное как набор таблиц, имеющих отношения (relations) друг с другом

В теории реляционных баз термин «relation» означает саму таблицу (!) а понятие relation устанавливется для кортежей(tuples) которые и образуют таблицу....
Ни в коем случае не трактовать как отношение между тьаблицами. Карма как теоретика сразу портится. LOL

И дайте разберемся вот с этим

Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен. Но ты знаешь, что Mongo (документная база) или Vertica (семейство столбцов), или Neo4j (графовая база) могли бы решить эту задачу за 0,0000x сек. И это удручает в работе с SQL базами.

1. Будьте аккуранты в таких выскзываениях, поскольку будет залочена таблица. Сервер баз данных будет отвечать на запросы клиентов в том же режиме, за исключением waiting lock acquiring запросов
2. ALTER TABLE на 8.5 который повесил продакшн сервер — это фейл DBA но никак не СУБД.
Как такой DDL попал на продакшн ? Как тестировали ?

В целом я согласен что ALTER TABLE выполняется «долго» особенно если менять тип данных ;)
Но для того то и дизайнится модель данных, применяется нормализация, чтобы потом избежать подобных казусов. И вцелом модель растет/модифицируется за счет роста отношений ( помните ? — это таблицы) и аттрибутов. К примеру MS SQL добавляет новые аттрибуты логически и не меняет физически каждую страницу данных. Тому на моих проэктах такого бардака нет и не предвидится.

PS ничего против NoSQL не имею

В целом я согласен что ALTER TABLE выполняется «долго» особенно если менять тип данных ;)

В MS SQL до версии 7.0 единственная операция в ALTER TABLE была ADD column. Заставляло хорошо думать, добавляло понимания что такое реструктуризация таблицы :).

Так это потому что Alter table modify column занимал 8.5 часов!)

А в условиях военного времени и 8,5 суток!

Автор сравнил SQL Server 6.5 with Mongo ?!

!?
Я просто вспомнил дела давно минувших дней :). И как когда то боролись с ресурсоемкими операциями — их просто запрещали :).

было дело ;)
много поменялось в лучшую сторону, но на способность инженера правильно мыслить это не должно влиять ;)

Ну как сказать... После того как ТО инженеры пишут очередной скрипт по рестарту Томкета «бо шо та где та течет» и «да пацаны дескрипторы не освобождают» мне хочется что бы обучение программированию в обязательном порядке начиналось на МС ДОС с 640 кБ памяти. Если уж это не поможет то я не знаю...

это не инженеры, это операторы ;)

Это именно инженеры.

www.facebook.com/...an/posts/1149980465080002
Без этого пост был бы неполным.

Начала новую серию статей: пока планирую в общей сумме отделаться тремя выпусками.
Отдельное спасибо Славе ) Без тебя я бы не справилась.

Классический срач в комментариях прилагается.

UPD.
удивительным образом удалось заткнуть глотки ревнителей реляционных схем ссылкой на производительность сильносвязанной структуры https://neo4j.com/.../how-much-faster-is-a-graph-database-re.../

Ахахаха, зачет!)
Эй, ревнители, заткнули вам глотки-то?))

//fixed

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

Вопрос автору: а сколько лет опыта и с какой (какими) RDBMS?

из статьи как бы очевидно его отсутствие

Так я думаю, может я что-то упустил. Ну не может же быть чтобы автор, не имея опыта работа с RDBMS, брался за сравнение с другими технологиями!

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

Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен. Но ты знаешь, что Mongo (документная база) или Vertica (семейство столбцов), или Neo4j (графовая база) могли бы решить эту задачу за 0,0000x сек. И это удручает в работе с SQL базами.
Так же само дурак может менять название поля/свойства в каждом объекте Mongo базы, тогда как в реляционной это выполняется 0,0000x сек. Автор не хочет понять простого — и что с того !!! Ни слова о целостности и согласованности данных в базах, как это дело поддерживается в зависимости от типа базы, каковы затраты.

Не обижайтесь, но по итогу как в анекдоте:
Я вижу, что переубедить вас не удастся, поэтому сразу перейду к оскорблениям.

Восприимчивость к критике, порой, может сказать больше, об авторе, чем сам текст.

Мы собирались на обед за круглым столом в Вандербилт-Холле. Беседа была живой и непринужденной. Здесь было неподходящее место для игры в амбицию, да это и не поощрялось. После обеда кто-нибудь из нашей группы или из гостей делал доклады на какую-либо научную тему, причем обычно в этих докладах вопросы методологии ставились на первое или хотя бы на почетное место. На докладчика обрушивалась резкая критика, благожелательная, но беспощадная. Она была великолепным лекарством от незрелых мыслей, недостаточной самокритичности, излишней самоуверенности и напыщенности. Кто не мог выдержать испытание, не возвращался в нашу среду, но многие из нас, бывших завсегдатаев этих встреч, чувствуют, что эти встречи были постоянным существенным вкладом в наше научное развитие.
Норберт Винер ©.

каждый раз одно и то же. Я уже девятую статью тут публикую. И толпы народа комментируют в негативном тоне мои работы (и в позитивном тоне тоже, а то сейчас начнётся «а чего вы туту публикуетесь, если вас все ругают»). Я читаю все ваши комментарии и отвечаю. В основном меня комментируют люди, не написавшие ничего. О каком благожелании вы тут говорите, если людям просто лулзов схватить интересно или выпендриться. Конструктивщина попадается крайне редко.

вот сам добейся... а тогда статьи пиши на dou
вот сам добейся... а тогда комментарии пиши
вот сам добейся... а тогда специалистом по БД считайся

Какой из вариантов вы имеете в виду?

Я уже девятую статью тут публикую

Я автор статей, текстов и постов...

У меня есть такой реальный опыт

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

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

О ужас и кошмар: описание подобного опыта выходит за рамки данной статьи, хоть вас он и интересует.

Змішались в купу люди й коні..

шел 10ый год похорон SQL. SQL никак не хотел залезать в гроб.

Это приведение сущностей к нормальным формам и сложности в отображении связей типа многие-ко-многим. Такие схемы тяжело читать и понимать их бизнес-применение
если, конечно, не учитывать ту довольно частную ситуацию, когда сущности являют собой нормальную форму.
Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен.
это происходит всегда? на любых sql субд с любым размером данных, количеством строк, набором индексов? вы взяли какую-то сферическую ситуацию и пытаетесь сделать из нее неоспоримый факт.
например, при очень интенсивной записи монга плодит 100600 тредов, отжирает всю возможную память и своп и вешает сервак к чертям собачим. правда я не скажу в какой ситуации. поэтому давайте считать монгу говном. а заодно все нереляционные субд.

puu.sh/sk8KV/6729021d1d.png

___upd:
«например» это не синоним слов «иногда», «бывает» и «может так случится, что..», «в отдельных случаях»
это вполне себе конкретизация: «вот этот ваш sql тормознутый». и звучит как утверждение.
а не как «иногда alter table занимает 8.5 часов», где подразумевается что в остальных случаях он не 8.5 часов занимает.

мне почему-то казалось, что полных идиотов в IT нет и что из контекста понятно, что «например ALTER TABLE длится 8,5 часов» — это пример частного случая.

правильно, давайте перейдем к оскорблениям.

мне почему-то казалось, что полных идиотов в IT нет
поэтому решили во что бы то ни стало опровергнуть это?


ранее по ветке:
Вы не совсем поняли посыл этой статьи. Я не критикую SQL
это точно ваша статья? вы ее вообще читали?

весь раздел Общие свойства технологии NoSQL вы противопоставляете NoSQL vs SQL, попутно выставляя реляционные субд эдакими тормознутыми, неудобными устаревшими монстрами.
это не критика? хм, ну если это не критика, то, наверное, просто обливание говном.


вы говорите о контексте? да вы сами не понимаете контекста «своей» же статьи.

пишите опровержение. Предлагаю название на выбор:

«SQL vs NoSQL. Бессмертная классика против моды»
«SQL vs NoSQL. Ложь и правокация теоремы CAP»
«SQL vs NoSQL. Лёгкость сопроводжения распределённых систем»

В последнем случае можно вообще без «vs», там и так всё легко и просто, выеденного яйца не стоит.

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

мне почему-то казалось, что полных идиотов в IT нет и что из контекста понятно, что «например ALTER TABLE длится 8,5 часов» — это пример частного случая.
Я вот новичек, почитал вашу статью, она ведь для новичков? Я вообще не знаю, что такое ALTER TABLE, видимо какая-то операция, длится стандартно 8,5 часов, ну там ± час для разных компьютеров..

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

Спасибо :) Я уже почитал в гугле.. Как я понял 8 часов это если очень-очень много данных, а в некоторых noSQL это вообще не актуально, и потому 0,000 с
Но если у меня в noSQL прослойка с тестами, я потрачу то же время переписывая тесты..
Честно говоря не встречал примеров огромных проектов построенных на какой-то одной БД, а уж тем более на какой-то одной не реляционной БД..

Отличия между какими-нибудь MySQL и MongoDB — это, в первую очередь, разный подход. Разная парадигма использования, пардон за пафос.

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

Вы же не будете лопатой забивать гвозди, ведь правда?

(из комментов ниже)

Проблема вот в чём. Заголовок статьи — «NoSQL vs SQL», как будто одно другому противопоставляется. «Лопата versus Молоток». Результат противопоставления предсказуем, происходящее в комментариях тоже предсказуемо.

Проблема в том, что большинство инженеров (простите, но это факт) продолжают использовать лопату во всех случаях жизни. Про лопату все знают, а молоток — первый раз в глаза видят. Вот и приходится объяснять в стиле Лопата versus Молоток.

у вас день не с той ноги начался?

Происходящее в комментариях предсказуемо :)

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

а вот я считаю, что проблема в том, что вторая часть инженеров используют молоток во всех случаях жизни, потому что начинаются статеек с хабра (а теперь и доу) в духе «реляционные субд масдай», а в итоге попадают в просак, потому что оказывается, что прилепили какую-нибудь монгу куда не нужно.

вот отличный пример слез после промаха с выбором технологий: habrahabr.ru/post/231213

Та не то что бы разрабы в просак попадают... Они то что, они часто до нагрузок и объемов не доходят. Это потом сидит операционщик и ломает голову — блин, а КАК из ЭТОГО быстро выгрести нужные данные на таких объемах? А база прилеплялась да, быстро и гибко.

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

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

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

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

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

ну sql очень гибкая штука, который позволяет городить убойнейшие вещи.
при должной сноровке и грамотном запросе (который иногда пишется на порядок дольше, чем ему отрабатывать) с помощью правильно чередуемых джоинов, подзапросов с group by и union можно делать прекрасные вещи.

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

INTO OUTFILE '/tmp/orders.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n';
и получат готовый отчет.

Нууу... Не всегда объем данных такое позволяет.

ну я просто как пример гибкости.
а то че, автору можно приводить сферические ситуации из вакуума, а мне нет?)

Якщо SQL-запит маслається довше, ніж 0.01 секунди, я продовжую оптимізувати запит, індекси, логічну структуру бази етц. Я не вмію писать запити за 0.01 секунди. Я слоупок.

Есть еще одна штука с этими NoSQL (или вернее с подходом «каждому типу данных свое хранилище»). Вот это мы будем хранить в Монге, это в Редисе, а вот для вот этого СВИФТ самое то. Ну и еще пару тройку систем. И потом со всей этой фигней попытаемся взлететь...

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

на любом языке можно написать фортрановскую программу©.
... и любую технологию(комбинацию технологий) можно загнать в неработоспособные режимы.

Да тут вопрос даже не в режиме...

... правда там скорее пример как не правильно готовить монго (ошибки проектирования базы по аналогии с реляционными ... им бы хотя бы пройти он-лайн курсы от самих создателей ...)

А вообще, да, сломя голову бросаться на технологии не стоит ... можно и не выплыть.

NoSQL противопоставляются реляционным базам (как можно догадаться из названия)
Not only уже трактуется как противопоставление?

NoSQL расшифровывается не «не-SQL» как это может казаться, а как «not only SQL». Как такое название можно трактовать как противопоставление!?

в статье это обосновано, там где про теорему CAP. Перечитайте

Что обосновано? Вы хоть понимаете что Вам пишут?

мне пишут:
1. похоже на рекламу Монги
2. реляционки круче всего
3. запрос ALTER TABLE выполняется только 8 часов и никак иначе
4. NoSQL это тот же SQL
5. не дадим умереть SQL
6. вы не так пишите
7. автор успокойся
8. Монго — Монго — Монго !!!

Вам какой пункт больше нравится?

может быть вы возьмёте на себя труд просвятить меня?

Наташа, внимательно (только ВНИМАТЕЛЬНО) прочтите то что я и Евгений ВАМ написали. Я понимаю что запись и чтение это разные операции, но попробуйте. И тогда поймете какое именно Ваше утвреждение мы советуем подправить.
И на будущее — комментарии к ЛЮБОЙ статье это способ ее улучшить. Прежде всего. Но если Вы будете всех посылать (а Вы посылаете) то ничего хорошего для Вас же не получится.

из опыта могу вас заверить, что комментарий к любой статье — это в первую очередь желание комментатора почесать своё ЧСВ. Конструктивные записи случаются крайне редко.

Видимо Вы так и не поняли суть этой ветки.
NoSql никогда не противопоставлялись реляционным СУБД. Название говорит о том, что не стоит зацикливаться только на одном «варианте» хранения и обработки данных. Есть альтернативные подходы.
И суть «Not only» и подчеркивает, что есть альтернативы, которые, возможно, будут более оптимальны в конкретных условиях.
И да, из контекста я ничего не вырывал. Это вы неправильно трактовали расшифровку аббревиатуры того, за что кидаетесь на амбразуры и чешете свое ЧСВ в довольно грубой форме

Рочків через десять ви будете згадувать ці коменти і вам буде невимовно соромно.

Але це нормально.

Это не обзор, это агитация за NoSQL (вероятнее всего, MongoDB). Причём не очень удачная.

Но прошло уже почти полвека с момента изобретения модели реляций: за это время системы хранения данных давно успели вырасти из «простых табличек» в распределенных дата-монстров. Создавая свою теорию, господин Кодд явно не рассчитывал на такое.
Реляционная модель не в состоянии справиться с этой задачей, так как была создана для других целей и в других условиях.

Не надо так. У вас по всей статье такое вот грубое и примитивное нагнетание эмоций на ровном месте. Реляционные СУБД (это не СХД, кстати) никогда не были «простыми табличками».

В то время, как реляционные схемы полагаются на принципы ACID, все без исключения NoSQL хранилища опираются на другие принципы, описанные в теореме CAP.

Монга и транзакции — это боль, мы в курсе.

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

Однако обратная сторона этой медали заключается в том, что вам всё ещё нужно уметь читать и интерпретировать нужным образом ранее записанную информацию «устаревших» форматов.

Как будто в обычном MySQL нельзя вместо ALTER TABLE, выполняющегося восемь часов, тупо создать новую табличку рядом со старой и писать новые данные туда. А старые данные оставить валяться в новой структуре. Вот уж действительно, бардак можно устроить где угодно.

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

Создавая свою теорию, господин Кодд явно не рассчитывал на такое.
У вас не получится «просто отпилить парочку-тройку таблиц или спокойно их партицировать в соседний кластер», а потом отправиться пить кофе-чай. Welcome to Hell.
Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен.

Вы не критикуете SQL? Это уже отличная технология? Я извиняюсь...

вы цепляетесь к нужному вам смыслу.

Значит Вы не смогли выразить СВОЙ смысл. Потому что у кучи людей впечатление наезда на реляционные БД.

мне извиниться надо? Или что вы от меня хотите?

Вы не стойкий духом инженер. Спорить начинаете, ногами топать.

Кроме шуток, рекомендую спокойнее смотреть на комментарии. Take feedback as a gift.

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

Адекватные люди пишут адекватные комментарии. Хорошие статьи хвалят, плохие статьи критикуют. Вы ни на секундочку не допускаете, что с вашим материалом что-то не то?

Ну и насчёт «на весь этот шлак отвечать»... А зачем? Такое впечатление, что вас заставили написать статью, а теперь заставляют огрызаться в комментариях. Не надо так. Не плюйте против ветра и не спорьте с толпой.

вы хотите мне что-то доказать?

Вы же не будете лопатой забивать гвозди, ведь правда?
Уж лучше забивать лопатой гвозди, чем копать молотком :-D
тупо создать новую табличку рядом со старой и писать новые данные туда
Вам всё равно придётся обходить ВЕСЬ массив данных строчка за строчкой. И переформатировать старые данные к новому виду. Переписывать эти проклятые индексы, если есть реплики — то и их записывать. Это всё очень долго. А вам, может быть, нужно просто записать что-то новое и всё.
Вам всё равно придётся обходить ВЕСЬ массив данных строчка за строчкой. И переформатировать старые данные к новому виду.
Зачем? Дмитрий же и сказал, что мы создаем новую таблицу. При связи 1к1 старую таблицу вообще не нужно будет трогать (ни «проклятые» индексы, ни чего более). Вот и запишете
что-то новое и всё

в реляцтонных таблицах join — один из самых тормознутых операторов. Вы предлагаете натворить вагон старо-новых таблиц со связями 1 к 1? Успехов вам в сопровождении.

Встречные вопросы:
Вы считаете, что всегда и везде ALTER таблицы занимает 8.5 часов?
Или Вы считаете, что в реляционной базе при каждой добавленной колонки я буду создавать новую таблицу?
Вы считаете, что достать одну запись с JOIN’ом это удар по перфомансу?
Вы считаете, что вместо добавления колонки (создания таблицы и использования индексов) проще смигрировать существующую систему на NoSQL?

вообще-то лично я вам ничего не предлагаю.

И что самое пикантное, самая большая проблема при миграции данных не в самой БД! Что NoSQL что RDBMS требуют времени на изменение структуры данных — чудес то на самом деле не бывает, и даже в самой-пресамой NoSQL БД данные записаны на меееедленный диск с кот-го надо прочитать и в него надо записать измененные данные. Выход для минимазации downtime — иметь обе версии структур данных, что вполне себе реально и для старых добрых RDBMS, потому что в таком случае шоу-стоппером становится не база, а приложение, кот-е должно безопасно и надежно работать со всеми имеющимись версиями структур данных. И тут да, на сену выходит слой абстракции БД в приложении.

Джойн на первичный ключах работает молниеносно. Такое впечатление что автор ни разу не видела планов запросов.

Автора отправить учится и читать мануал. Как работают джойны, индексы, надо знать. Что таакое Nested Loops, hash join, merge join знать очень неплохо. Также хорошо знать что такое density, selectivity и как с помощью них оценивать эффективность и ндексов и структуры данных. Ну и, наконец, открою вам маленький грязный секрет: на больших таблицаз не используется ALTER, а применяется такая последовательность: Новая таблица с новой колонкой, залить данные из старой, переименовать старую, переименовать новую, включить индексы для новой таблицы. Даже на 700 млн строк с почти сотней полей работает значительно быстркк 8 часов.

из ваших слов можно подумать, что любой ALTER работает только 8 часов, ни больше, ни меньше.

Новая таблица с новой колонкой бла-бла...

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

Я же говорю учиться, учиться и еще раз учиться. Например, вы удивитесь, но единицы записи в таблице не строка, а страница или блок, именно поэтому в индексах используется B-дерево, чтобы один надо заетмал блок и мог быть очень быстро считан. Индескы и реплики не надо переписывать, их надо создать после переливания таблицы, как это принято делать в мире беспринципного SQL. Ну и, конечно же, операции не стоят ничего, все упрется в производительность диска. На мошной машине с быыстрыми дисками 100-300 тыс записей в секунду вы добъетесь запросто. И еше скажу по секркту, что подобные миграции обычное дело в мире бездушного энтерпрайза.

А в NoSQL цветочные феи на единорогах порхают от байта к байту :).
Пардон не удержался :).

я вот не совсем понимаю, речь идёт о простом копировании данных из таблички в табличку или изменении их формата? Например. У вас есть поле «адрес». Из него вам надо получить три поля «индекс», «улица», «номер дома». Как вы это сделаете, не прочитав каждое значение?

Т.е. нужно распарсить адрес на составляющие? Это НЕ реструктуризация данных, это задача гораздо сложнее — вам нужно парсить адрес и верифицировать его части. Поверьте человеку кот-й посвятил этому несколько лет — сложности этой задачи НЕ в БД, ее типе и структура данных.

ну почему сразу вы отказываетесь от задачи? В NoSQL мы бы просто записали новые данные. Ровно то, о чём я написала в статье. А вы тут начали придираться и извращать, что всея-реляционки и так всё могут. Не могут. И NoSQL не всё могут. У каждой технологии свои особенности.

Я не отказываюсь от задачи. Я эту задачу решал 15 лет тому назад. Я Вам объясняю, что корректный парсинг адреса это НЕ проблема БД — это проблема интерпретации адреса и верификации его частей.
Деццкий сад...

И да, геокодирование потом выполнялось сохраненкой внутри MS SQL.

Дачные улицы с цифрами, номера корпусов и прочий ад? Решпект и уважуха.

Немецкие и французские. С ошибками, умляутами и прочим. Да, Гугль тода показывал в качестве карт спутниковые снимки размером с большую почтовую марку.

Я же говорю — маленькие носиквельные феи летают от цветка к цветку на красивых единорожиках. Какие диски, какие страницы, о чем вы?

вы не читали статью

Перепроектирование границ агрегата или создание новых узлов графа из атрибутов существующих узлов ничуть не лучше классического ALTER в базе SQL: вам всё равно придётся последовательно обходить значительную часть записей базы и исправлять их.

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

не можете. У вас появляются «мусорные» поля, расползающиеся на старую и новую структуру данных. Проблема одна и та же, но решения два принципиально разные в SQL и NoSQL. Вы знаете своё решение в данной ситуации и не хотите слышать про альтернативные пути.

Нету никаких «мусорных» полей. Нету.
Есть проблема отображения структур данных в БД на структуры данных и объекты в приложении. Это да. И тут есть один козырь старых, тупых, негибких RDBMS — stored procedures and views...

И тут есть один костыль старых, тупых, негибких RDBMS — stored procedures and views...

В кривых руках все костылем становится.

Если бы дело было только в кривых руках — то в большинстве OLTP приложений сейчас, как и 15 лет назад, писали бы 90% логики в хранимках....

Руки руки. И понимание. Потому что к примеру я пишу об views и SP как ЕЩЕ ОДНОМ способе абстрагировать структуру данных от приложения, а не как о панацее и месте для раелизации ВСЕЙ бизнес логики.
Собственно все комментарии «ретроградов», «отсталых реляционщиков» и прочих кот-м автор «заткнула глотки» сводятся к тому что серебряных пуль не бывает и каждому инструменту свое место, а NoSQL все таки расшифровывается как Not Only SQL.

А какую часть бизнес-логики стоит заносить в хранимки?

Depends.
Я в СП выносил то, что можно просто обработаь на сервере средствами самого T-SQL. Или то что требовало инкапсуляции прав.

Вообще-то во многих проектах, где я принимал участие, так и есть) Может не 90% логики, но значительная ее часть. Многое зависит от требований и подходов (и от команды, само собой), но опять же, какие-то пакетные задачи или операции по обработке данных, подготовка отчетов, бизнес-логика, связанная с конкуренцией и одновременным доступом, и «тогдалие» — все это логично и более правильно размещать в СУБД.

ну поздравляю, значит во многих проектах где ты принимал участие треш и угар с лучшими подходами из 50-60х годов

Спасибо, посмеялся)

Я ж специально подчеркул — OLTP системы, тоесть батчинг и репортинг — не совсем кейс.

Да, OLTP системы. Банковские и платежные системы, в частности.

мне везло больше — я с трешем «вся логика в сиквеле» я лет 10 серьезно не сталкивался.

Нигде не говорил про «вся логика», не надо передергивать)
Ну как сказать, «везло». Это очень условно) Например, я часто сталкиваюсь с тем что бизнес-логика в приложениях, да, которые уже после миграции с «треша и угара», как дядя выше написал. Везение еще то, я могу сказать. С базами работают разные системы, для каждой системы свой подход и своя реализация и свое приложение, реализующее бизнес-логику. Т.е специально подчеркну, с одной базой работают разные системы и как результат, разные приложения. Часть приложений — in-house, часть — купленные. В случае если возникает проблема, например ©, с производительностью, естественно оказывается что проблемные запросы идут из приложения. Чтобы изменить приложение, сначала поставщика или местных разработчиков нужно «убедить» в том, что это таки проблема приложения, а не базы. Сделать это очень сложно, так как религия таких людей — корень всех проблем в базе) Даже если они видят своими глазами проблемный запрос с планом и беспроблемный, все равно продолжают на голубом глазу говорить что у них «все летает». Ведь не поспоришь. Но даже если этот этап пройдет, наступает следующий — оптимизация. И тут оказывается, что приложение само генерирует запросы, к примеру, и все в недоумении разводят руками, мол, нет такой возможности поменять запрос. В результате нужно придумывать либо заплатки, либо workaround-ы, например, чтобы после какой-нибудь невинной DDL-операции подхватывался правильный курсор, а не тот, в результате которого запрос работает в десятки раз медленнее. И таких заплаток со временем появляется все больше. Вот именно для того чтобы избежать подобной @ботни, хорошо и удобно когда какая-то часть бизнес-логики, которая относится к «kernel functionality», находилась в базе или хотя бы чтобы была возможность внесения быстрых изменений.
А так-то да, кому в чем «везет».

Чтобы изменить приложение, сначала поставщика или местных разработчиков нужно «убедить» в том, что это таки проблема приложения, а не базы. Сделать это очень сложно, так как религия таких людей — корень всех проблем в базе
вот это — основное. Как обычно, основные проблемы в людях а не в технологиях :)

Ой, ну конечно нет! Конечно же, люди — это просто корень зла, если бы люди были идеальны, то и проблем бы не было!
Давайте начнем с того, что такие проблемы с производительностью могут возникнуть в любой момент для сложных приложений и для больших объемов данных, и нужно быть готовыми чтобы решать такие проблемы, а не искать козлов отпущения или ошибку в ДНК отдельных людей.
А в отношении технологий у меня прямо сейчас есть прекрасный пример. Например, есть сервер с базой и сервер с веблоджиком и четырьмя доменами (неважно зачем, вот такая вот архитектура). На сервере с базой, к примеру, 128G, а на MW сервере — 256G, и не всегда хватает. В случае реализации логики в базе таких ресурсов не нужно было бы. Но даже в минимальном варианте «поставки» если база занимает может в районе 10G, память резервируется в районе 3-4G, но сервисы приложения при старте сразу «съедают» примерно 8-12G.
Дополню. То есть, если на сервере с базой ОП 16G, то на MW сервере — 32G.

Давайте начнем с того, что такие проблемы с производительностью могут возникнуть в любой момент для сложных приложений и для больших объемов данных, и нужно быть готовыми чтобы решать такие проблемы,
Я даже больше скажу — что не надо быть готовым их решать, надо их просто предвидеть и проводить нагрузочное тестирование перед выкаткой релиза в прод или изменении маркетинговой стратегии. И все. Из моей практики: на проде после выкатки блокер с перфомансом вылез. Оказалось что команда перф тестеров, занизила тестовую нагрузку в 10 раз по сравнению с требованиями. Технологии виноваты?
. В случае реализации логики в базе таких ресурсов не нужно было бы.
Осталось сравнить стоимость и время разработки, требуемую квалификацию девов и наличие их на рынке, стоимость рефакторинга и внесения изменений.
А железо в типичных случаях стоит единицы процентов от стоимости разработки.
Я даже больше скажу — что не надо быть готовым их решать, надо их просто предвидеть и проводить нагрузочное тестирование перед выкаткой релиза в прод или изменении маркетинговой стратегии. И все.
Я тоже больше могу сказать. При тестировании все работает, при выкатывании появляются проблемы. На проде есть проблема, на ЮАТ — нет проблемы, все идентично при этом.
Осталось сравнить стоимость и время разработки, требуемую квалификацию девов и наличие их на рынке, стоимость рефакторинга и внесения изменений.
Естественно, стоимость рефакторинга выше. До определенного момента, естественно, так как стоимость латания и вымучивания у заказчика новых аппаратных ресурсов тоже высока. Про квалификацию я вообще не понял. Типа — разработчиков, способных писать на SQL и процедурных расширениях SQL, мало и они дорого стОят что ли?)
а проде есть проблема, на ЮАТ — нет проблемы, все идентично при этом.
Значит не идентично. Кэп.
Естественно, стоимость рефакторинга выше. До определенного момента, естественно, так как стоимость латания и вымучивания у заказчика новых аппаратных ресурсов тоже высока.
У меня другой опыт: заказчик лихко соглашается докупить железа, но при этом жестко ставит сроки и(или) режет косты на команду разработки.
Так что вишь, there is no silver bullet.
Типа — разработчиков, способных писать на SQL и процедурных расширениях SQL, мало и они дорого стОят что ли?)
Их сложней найти на рынке чем типичных джавистов-дотнетчиков. Особенно если мы говорим про хайлоад, и там нужны люди с опытом и квалификацией.

У вас из уравнения стоимости выпали ДБА и прочие операционщики...

... и еще много чего. Упростил.

Я даже знаю почему...

Значит не идентично. Кэп.
Если чего-то не видел собственными глазами, не значит что такого не бывает)
Бывает и хуже. Есть запрос, у него несколько дочерних курсоров, часть с нормальными планами, часть — с ужас-ужас. Часть пользователей работает с курсорами, у которых нормальный план, и довольны, а некоторые кричат — все пропало. Не скажешь же им, что они козлы, потому что у их коллег все хорошо)
У меня другой опыт: заказчик лихко соглашается докупить железа, но при этом жестко ставит сроки и(или) режет косты на команду разработки.
Ну это очень сильно зависит от железа и от лицензий того, что на железе будет работать. А стоимость там меняется иногда очень сильно с добавлением процессорных ядер, памяти... А когда выясняется что заказчику нужно чуть ли не каждый год «докупать», то глаза на лоб лезут очень быстро)
Их сложней найти на рынке чем типичных джавистов-дотнетчиков. Особенно если мы говорим про хайлоад, и там нужны люди с опытом и квалификацией.
А для джавистов-дотнетчиков опыт и квалификация не нужна что ли?)

Джавистов и дот-нетчиков тот же ЕПАМ готовит у себя на пре-проде вагонами. А вот SQL да, беда.

Ну хоть какая-то польза от статьи и информации в комментах получилась. Надо будет на линкеде переписать себе профиль, указав побольше на TSQL.

Если чего-то не видел собственными глазами, не значит что такого не бывает)
Я верю в науку и в 100% повторяемый результат при повторяемых исходных данных. Впрочем иногда бывает так что незначительное изменение входных данных рушит все что только можно...
Ну это очень сильно зависит от железа и от лицензий того, что на железе будет работать.
Это безусловно очень сильно зависит от кейса. Просто отмечу, что сейчас тренд — горизонтальное масштабирование и опен сорс где только можно. Это приводит к тому, что супер-железяки покупать не надо. Повторюсь — ни разу не утверждаю, что описанный мной подход — silver bullet.
А для джавистов-дотнетчиков опыт и квалификация не нужна что ли?)
Вот внезапно цена ошибки ниже, ее проще-раньше обнаружить.

слушайте, я не заставляю вас стать адептом NoSQL. Я рассказываю, что есть альтернативные пути. Не хотите знать — не парьтесь.

А есть еще 4-я нормальная форма кот-й структура по сараю. Но и производительность тоже...

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

Конечно я прочитаю каждое значение, преобразую и сохраню, и это будет очень быстро. Потому что база данных читает за одно чтение страницу, а не запись, и страница эта содержит пару тысяч строк, ну или как настроите. Далее, сохранять вы тоже будете страницу, для этого только понадобится правильно настроить размер батч инсерта и транзакции, в SQL scripte или программе. Таким образом за одну запись будет физически записано тысячи строк. Это быстро. Это очень быстро. И это типическая задача.

наверное все создатели NoSQL — полные лохи, раз всё так просто и никаких проблем нет.

Вы не поняли как и зачем NoSQL были созданы. Они нужны для распределенной средыс десятками и сотеями серверов. Отсюда же все эти условия к partition tolerance и consistency. Поэтому и Map Reduce, которые не имеет практического смысла на одной машине. Но то что вы описали в статье легко решается через СУБД.

как бы кэп.
Вы только что кратенько пересказали суть материала добавив «десятки с сотнями». Но тем не менее, автор пишет говно. С этим трудно не согласиться.

Нет десятков сотен серверов — вам не нужен NoSQL

Ну мне нужен был от 3 серверов. Но с дублированием записей и обязательным кворумом на запись и чтение. И шло лесом практически всё из NoSQL, остались только Riak и Cassandra. И без всяких монгей :)

Кстати именно так работает реструктуризация баз в 1С 8.

Я би ще додав наступне питання:

в реляцтонных таблицах join — один из самых тормознутых операторов.
А де ж тоді join виконується блискавично порівняно з RDBMS? Де той silver bullet, який дозволить нам забути про ціну джойна?

Какие интересные подробности всплывают.

Ставлю на курсор.

в общем я провел тест, аналогичный тому, что по ссылке и у меня получился вот такой результат:
puu.sh/skwye/bb073ce97e.png
пруфы, запросы и структура субд там же где и у автора (их нет).

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

Ваша проблема в том, что вау-эффект от noSQL давно прошел, большинство уже ее распробовали, и знают ее достоинства и недостатки.

Я бы сказал больше: самый тормознутый на самом деле — SELECT!

У вас очень сильно устаревшие данные о возможностях RDBMS. Даже мускуль уже не совсем так работает :) ( можно тут почитать — dev.mysql.com/...reate-index-overview.html ).
Вертика и редшифт — это различные варианты эволюции посгреса, которые прекрасно себя чувствуют в кластере, и даже в процессе эволюции — они не ушли от SQL как основного инструмента работы с данными :) Колоночный датаэнжин есть и у мускуля :)
По поводу прозрачности изменения структуры у носиквел решений — это тоже не совсем и не всегда так прозрачно как хотелось бы — попробуйте изменить структуру данных в паркете и обработайте датасет, в который попали паркетины разных типов одновременно...
В общем — всё очень не однозначно. Единственный серьёзны минус хороших RDBMS — это их цена — она очень сильно кусается (можете для примера глянуть на расценки Вертики). Носиквел решения условно бесплатны и некоторые задачи действительно проще решать при их помощи (хороший пример — парсинг террабайтых папочек с лог файлами).
И с чем я действительно согласен — так это с тем, что CAP теорему никто не отменял — для кластерных RDBMS решений — в том числе :)
А статья в целом — выглядит таки как реклама монги :)

у меня складывается впечатление, что тут кроме Монги никто ничего не знает. Открою страшный секрет: в моём сердце первое место принадлежит Neo4j. И если уж мне захотелось бы что-то рекламировать, то уж точно не Монгу.

Монга и транзакции — это боль, мы в курсе.
Транзакционность в любой распределенной системе — это боль. Это отправная точка в понимании, зачем нужно noSQL.
Выделить проксирующий слой полезно и внутри одиночного приложения, таким образом вы получаете некоторую страховку от кривых рук джунов, норовящих производить запросы в базу напрямую.
Помогает ВСЕГДА. Более того — фигачить прямые запросы в БД из любого места приложения это несусветная глупость и прямой путь в ад, включая его самый последний круг посвященный чувака плююющим на инфобезопасность.
Например, ALTER TABLE занимает 8,5 часов, при которых сервер базы недоступен.
— а голову применять не пробовали?
В общем статья оставляет удручающее впечатление — оспаривать можно через строчку т.к. абсолютно очевиден биас автора.

Я кстати реализовывал гибкую схему хранения с изменяемой структурой полей объектов внутри реляционной БД НЕ доходя до 4-й нормальной формы.

Ну для большинства NoSql есть рекомендация не использовать их, если мало серверов. Их распределенность имеет смысл, если число нодов десятки и сотни. Отсутствие структуры и распределенность само по себе не ново: например LDAP, сетевые и иерархические базы дореляционной эры.

То, что в 2000 году приписали реляционным БД невозможность реализации устойчивости к партиционности, не делает эти системы сегодня таковыми, которые не позволяют кластеризировать хранение данных. Разве есть технические ограничения
Технические ограничения и приводят к CAP теореме. Задайся вопросом, как реализовывать транзакционность в распределенной системе.

поделись же пруфлинком не тяни (попкорн)
(ставлю что там будет про многофазный коммит и координатора транзакций)

Это последний мой ответ на ваши комментарии (я с хамами не люблю общаться)
тоесть пруфлинка не будет — ожидаемо. Остальной пафос поскипан :)

Неправда, доказана в 2002 Srsly, можно было в википедию залезть на секунду.

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

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

В википедии написано что-то странное:

> This last claim has been criticized, however, this reference does not offer a peer-reviewed formal proof — just an informal assertion on a blog posting.

У меня ACM членства нет. (Вообще, интересно, у скольки человек с DOU оно есть? как-то мы массово проходим мимо этого, а ведь в США и ближайших местах это один из самых важных источников свежих данных в CS...)
И соответственно самому прочитать, является ли оно реально доказательством, тем более проверенным (а ошибиться банально) — не получится.
Надо бы спросить кого-то более знающего. Вон коллега Денис Дон, при всей его чрезмерной резкости, явно на чём-то основывается.

А ещё есть, например, такие соображения:

> И везде происходит один и тот же идиотизм: все характеристики признаются «булевыми». Типа либо есть consistency, либо её нету. То есть нет даже попыток количественно измерить inconsistency, и сопоставить её с availability или другими характеристиками.
> Казалось бы, это очевидно: в реальной жизни никто не готов пожертвовать полностью ни одной характеристикой. Ведь отсутствие availability в такой постановке означает, что систему можно вовсе не включать, а отсутствие consistency даёт нам разрешение отвечать ’42′ на любой запрос.
> В жизни интересует что-то типа «дайте мне гарантиии длины простоя не более 10 минут и гарантии того, что запрошенные мной данные будут когерентны с задержкой не более 20 минут».
> И вот тут можно бы начинать обсуждать, сколько нод и в какой конфигурации нужно подключить друг к другу так, чтобы получить эти характеристики.

и рядом же тот же автор -

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

(источник)

И даже такая банальность, как то, что consistency в CAP — durability в ACID (подробнее обсуждали тут).

Да это не обязательно касается бд, пожалуйста, любой кластер (в ситуации split brain), таблицы маршрутизации и т.д. Для кластеров выбирают зачастую consistency и убивают проблемные ноды (см. fencing), протоколы маршрутизации действуют из соображений, что рано или поздно как-то оно наладится (eventual consistency).

Так или иначе, во вполне обычной ситуации, где есть два датацентра, связанных одним (логическим) линком, и где этот линк почему-либо отваливается, мы все равно встаем перед проблемой, которую описывает CAP. Мы можем или продолжать писать данные, рискуя что в конечном счете при синхронизации получится конфликт, либо перевести приложения во вторичном ДЦ в рид-онли/вывести из лоад балансинга/...

Да это не обязательно касается бд, пожалуйста, любой кластер

Да.

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

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

Для кластеров выбирают зачастую consistency и убивают проблемные ноды (см. fencing)

Мне больше нравится вариант кворума (по крайней мере пока проблема только в разрыве связей и остановке отдельных узлов, а не в некорректности их работы).

протоколы маршрутизации действуют из соображений, что рано или поздно как-то оно наладится (eventual consistency).

Да. Но это слишком лёгкий случай. Даже во взаимодействии нескольких процессоров в одном хосте стараются усиливать гарантии до sequential consistency, где это требуется.

Мы можем или продолжать писать данные, рискуя что в конечном счете при синхронизации получится конфликт, либо перевести приложения во вторичном ДЦ в рид-онли/вывести из лоад балансинга/...

Либо перестраивать схему так, чтобы формулировать изменения не в виде конкретных изменённых данных, а в виде операций (это работает начиная от простого икремента счётчика до полноценного денежного перевода). Либо ещё варианты для более частных случаев.

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

Теорема CAP ? Я не видел доказательства «теоремы». Это гипотеза. И пока она не опровергнута — не более. Возможно, просто никто не пытался ее опровергать.

Денис, Вы член ACM? Если да — могли бы вытащить текст предполагаемого доказательства и оценить самому. Если нет — мы все тут на равных — довольствуемся слухами и вынуждены оценивать по неполной информации методами шпионов.
А в этом случае «Возможно, просто никто не пытался ее опровергать» выглядит, мягко говоря, странно — в области, в которую вбуханы миллиарды и есть уже более сотни готовых решений, никто не пытался опровергать одну из самых важных компонент теоретической базы??

То, что в 2000 году приписали реляционным БД невозможность реализации устойчивости к партиционности, не делает эти системы сегодня таковыми, которые не позволяют кластеризировать хранение данных. Разве есть технические ограничения по использованию нескольких серверов БД? Или на одном сервере БД разделять сущности на разные файловые группы?

Речь не о нескольких серверах или файловых группах. Или Вы не понимаете, о чём CAP гипотеза, или чрезмерно утрируете, иначе это крайне сложно понять.

Представьте себе, что у вас должна быть 5 идентичных полных копий данных (например, в 5 самых крупных городах Украины). В методах SQL+ACID движков это означает, что при разрыве связи с любым из них или остановке сервера никакая операция не будет выполнена, потому что для подтверждения всей транзакции требуется ответ о состоявшемся коммите от всех пяти ДЦ. Неважно, в каждом только один сервер или 100500 в кластере; неважно, как там данные распределы по серверам, по «файловым группам», физическим дискам, etc. — каждый отвечает промежуточным коммитом, только тогда арбитр может разрешить финальный групповой коммит.

CAP гипотеза всего лишь попытка описания в математических терминах банальной бытовой истины «если вы не можете достучаться до другого хранилища, вы этого не можете и данные в нём не будут актуальными, и вам надо выбирать — или расхождение, или невыполнение операции». Это настолько банально, что крайне маловероятно, что оно будет неверным.

Да, в математике такие случаи (банальное оказалось неверным) бывают. Или наоборот, банальность крайне тяжело доказать. Не буду глубоко вдаваться в примеры, там много интересного. Для нас сейчас главное — что для того, чтобы истина бытового уровня перестала быть таковой, нужно не просто отсутствие доказательства, нужен конструктивный контрпример. Например: матан, 1-й курс: всякая фундаментальная последовательность сходится. 2-й курс: нет, не сходится, если у вас предел может не принадлежать множеству значений (рациональные числа, иррациональный предел) или метрика не соответствует необходимым ограничениям, как правило треугольника. Не могу себе даже приблизительно представить, что будет эквивалентом в случае CAP, но уже известно множество вариантов ослабления требований каждой из трёх букв.

Для меня лично в NoSQL есть только одно преимущество — отсутствие жесткой табличной структуры, что в некоторых случаях позволяет более эффективно работать с данными не имеющими однородную структуру и имеющих тенденцию постоянно менять свою структуру.

Это хороший пример, насколько разные NoSQL базы и насколько по-разному они используются.
Например, Cassandra появилась в результате реализации теоретических обоснований, что B/B⁺/etc. хранилище не является самым эффективным, если ослабить требования на упорядочённый просмотр ключей и операции нечёткого поиска по ключу, и оставить только точный поиск, перейдя к хэш-таблицам на диске. (В её доке есть ссылка на эту научную работу.) Следом за ней на такой же базе был сделан Riak. Но я не могу себе представить SQL DB, которая бы не позволила операции вида «select * from table1 order by id asc». Опираясь на это, в обеих базах была резко упрощена реализация multimaster шардинга с дублированием данных в заданном количестве копий и с балансом между узлами. В остальном же это изначально были банальные плоские key-value (сейчас частично отошли от этого, но не сильно).

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

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

Вот как раз мой случай — Riak был выбран из-за многоузлового дублирования и кворума на чтение и запись. В этом режиме база работает, пока есть минимум 2 из 3, или 3 из 5, или 4 из 7 узлов, и так далее. Добиться такого с типичными реляционками напрямую нельзя; можно своим клиентом, который будет обеспечивать тот же кворум (в другой версии проекта так и было сделано). Да, при этом нет никакой логической связи между таблицами, кроме явно выполненных на клиенте, нет транзакций... на такое построение надо переучиваться. Но ТЗ выполнялось.

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

Другая версия проекта была до Riak?

Нет, изначально создавался с расчётом под него. А потом начались чудеса. Оказалось, Riak (по крайней мере по состоянию на 2013), точнее, его реализация eleveldb, крайне плохо относилась к шаблону деятельности «у нас всего 50-200 ключей, но они все меняются не реже раза в минуту», а некоторые корзины выглядели именно так. (Его больше затачивали на вариант типа «мы тут вольём 100500 миллионов ключей, оно быстро это сделает и дальше будет лежать с небольшими изменениями, или с полной вычисткой всей корзины».) Нормально на [e]leveldb (как в любом LSM движке) должно работать сжатие логов, но тут оно почему-то дико тормозило с выполнением, и объём, который должен был не превышать дискету, раздувался до гигабайтов (а когда оставили в покое — сдулся сам до нормального за ~3 недели). Копаться в этом не было средств, сделали KVS на постгресе(!) простыми двухколоночными таблицами с реализацией кворума средствами самого клиента. Выглядело как жуткое извращение, но сработало. Заодно мне понравилось то, что появилась возможность добавить процесс аккуратной фоновой ревизии данных — за счёт возможности делать выборки в духе «select id from ... order by last_time_checked limit 100».

как проходила миграция (в общих чертах)?

Остановили и скопировали клиентом. Было достаточное окно для этого.

Пора терминологию менять, ибо SQL — это язык, а не способ хранения и обработки. Аж бесит

Я старалась написать максимально доходчиво, без всей этой ум-за-разум заходящей бредятины с пятью терминами в предложении из десяти слов — пока до конца предложения дочитаешь, уже забудешь, с чего там всё начиналось. Очень не люблю такой стиль. Решила пожертвовать «реляционными базами» в заголовке ради лаконичности и наглядности «SQL». Ну и в тексте через слово «реляционные» тоже не особо читается, иногда лучше использовать синоним «SQL».

вы извращаете смысл сказанного мной.

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

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

«реляционными базами»
и
«SQL»
, соответственно подобное упрощение воспринимается как ошибка.

заголовок так лучше смотрится. Вам подходит такой ответ?

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

Техническая статья на доу! Слава Наталье Ниште!

И Славе Конашкову. Сама я бы такой сложный материал не рискнула публиковать.

Это сложный материал !?
O tempera, o mores!

вы должны понимать, что моей целью является не написание трёхтомной коллекции подарочных книг, а лаконичные три-четыре статьи на выбранную тему. Я не могу вместить в них все тонкости и особенности необъятного мира технологий. Всегда будут люди, подобные вам и прочим «уязвлённым комментаторам», кричащие «Не так!» Если вы считаете, что можно написать лучше — чем я вам мешаю?

Да. Пункт — «Написать статью на Доу/Хабре/ итп на тему NoSQL». Дата. Результат.

Разумеется для того, чтобы потешить собственное ЧСВ. Разве могут быть другие причины? А может быть, чтобы позлить вас.
Я ещё не решила, какой из вариантов мне больше нравится — пусть будут оба.

Судя по реакции на аргументированную критику, первый ответ правильный.

Підписатись на коментарі