NoSQL технології на прикладі MongoDB

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всім привіт!

Я Сергій Моренець, розробник, тренер і письменник, часто виступаю з вебінарами і воркшопами.При написанні четвертої частини свого циклу «Розробка Java додатків» я вирішив детально викласти використання NoSQL технологій, в першу чергу MongoDB. Це досить складна тема, особливо для тих, хто звик використовувати реляційні бази даних, тому я вирішив написати окрему статтю, де оглядово розповісти про NoSQL проекти, про їхню історію і, зокрема, про MongoDB.

Перш за все, що відноситься до NoSQL технологій і як вони з’явилися на світ? Сучасна історія баз даних починається в 1970-му році в роботі Едгара Кодда, де він вперше ввів такі поняття як:

  • Tuple (кортеж) — невідсортований набір атрибутів (запис)
  • Relation — набір кортежів (таблиця)
  • Constraints — обмеження, що накладаються на схему даних
  • Normal forms — результат реструктуризації або нормалізації таблиць
  • Query language — мова запитів

З тих пір з’явилося досить багато реляційних СУБД, але в цілому, ми все ще використовуємо ті визначення, які з’явилися 50 років тому. У 90-ті роки була спроба створити об’єктні бази даних, але вони поступилися своїм місцем ORM-фреймворкам. Отже, які ж основні характеристики є зараз у будь-який реляційної бази даних:

  • Фіксована схема даних (набір стовпців для таблиць)
  • Транзакції (ACID)
  • Підтримка SQL (ANSI SQL або розширення)
  • Нормальні форми

Це призводило до різного роду складнощів і обмежень:

  • Блокування рядків/таблиць/схем під час транзакцій
  • Ускладнення SQL запитів (кількість поєднуваних таблиць) призводило до падіння продуктивності сервера і збільшення витрат пам’яті
  • Дані можна було розміщувати на одному фізичному сервері
  • Неможливість динамічно змінювати схему даних
  • Неможливість використовувати складні типи даних (масиви, maps, JSON або XML-структури) і вести пошук по ним

Однак все це було не настільки критично, поки кількість одночасних користувачів (транзакцій) і обсяги даних було не надто велике. Але ось настали 2000-ні роки, а разом з ними і ера Web 2.0. Кількість користувачів Інтернету різко зросла, разом з ним з’явилися проекти, яким було потрібно оперувати надвеликими обсягами даних (терабайти, а потім і петабайт).

У цей момент з’явився термін scaling (масштабування), потім еластичність, як спроба подолати природні обмеження розміщення даних на одному сервері. З’явилися нові патерни — sharding/partitioning і реплікація. Старі добрі реляційні СУБД їх не підтримували або ще не підтримували, тому нові ІТ-гіганти почали створювати свої власні технології:

  • 2006 року компанія Google представила проект BigTable
  • 2007 року виник проект Hadoop
  • У 2008 році Amazon почав розробку DynamoDB
  • У 2009 році компанія 10Gen представила MongoDB
  • У 2010 році з’явився проект Hive, який запропонував зручну мову запитів для Hadoop

Все це були сховища даних і системи з керування даними, які вже не були реляційними. Потрібно було спочатку придумати назву, а потім каталогізувати їх. І ось в 2009 році на одній з конференцій, де обговорювали BigTable і DynamoDB, придумали тег «Not only SQL», як пояснення, що нові системи не підтримують універсальну мову запитів SQL. Цей тег згодом скоротили до NoSQL. Але NoSQL технології не є однорідними, а діляться на 4 категорії (або моделі даних):

  • Документні (document store)
  • Ключ-значення (key-value)
  • Wide-columns
  • Графи (graph)

Такий поділ не означає, що кожна NoSQL БД відноситься тільки до однієї категорії. Наприклад, Amazon DynamoDB підтримує і документную модель, і ключ-значення. Більш того, в останні роки виділили ще дві категорії:

  • Search engine (повнотекстовий пошук)
  • Spatial (географічні та геометричні дані)

NoSQL технології широко застосовуються в Big Data проектах як сховища великих обсягів інформації, яку потрібно аналізувати і обробляти. Чим же NoSQL рішення відрізняються від реляційних СУБД?

  • Відсутність підтримки SQL або якоїсь універсальної мови запитів. У кожної технології є своя власна мова, це пояснюється відмінностями в моделях даних і підтримуваних операціях. Хоча, наприклад в Apache Cassandra мова CQL дуже схожа на SQL
  • За замовчуванням транзакції відсутні для прискорення роботи (вставки/зміни даних). Хоча в MongoDB 4.0 вони були введені на прохання розробників
  • Неможливість об’єднувати в одному запиті різні relations (join в SQL)
  • Гнучка схема даних, хоча і з можливістю її валідації
  • Відсутні нормальні форми
  • Eventual consistency (на противагу ACID і strong consistency в реляційних СУБД)
  • Підтримка складних типів даних (списки, набори, maps, UUID, JSON, вкладені об’єкти)
  • Вбудована реплікація і sharding

У той же час в NoSQL рішеннях є і звичні нам фітчи:

  • індекси
  • ідентифікатори об’єктів

Які мінуси NoSQL технологій:

  • Відсутність єдиної стандартної мови запитів (такої як SQL)
  • Відсутність єдиного API для доступу до даних (JDBC). Для кожної NoSQL СУБД є свій власний драйвер (в тому числі і на Java), а для Redis, наприклад їх цілих три.
  • Неможливість використовувати Java EE (JPA), хоча є вже покинутий проект Hibernate OGM як спроба використовувати Hibernate для mapping’a

Не всі з цих мінусів є перешкодами. Наприклад, є популярний проект Spring Data для абстрагування доступу до сховищ даних (як NoSQL, так і реляційних). В Eclipse Microprofile з’явився аналог — JNoSQL. Але в цілому наявність різних моделей даних є безперечним плюсом. Більш того, з’явився такий термін як Polyglot Persistence, коли ви відмовляєтеся від єдиної (реляційної) БД на вашому проекті, а використовуєте ті сховища, які найкраще підходять для ваших завдань. Просто всі ці особливості ми розповідаємо на наших тренінгах по NoSQL.

Що ж реляційні бази даних? Для того, щоб не програти в цій еволюційної битві сховищ даних, деякі реляційні СУБД перетворилися в NewSQL-БД. По суті, вони мають ті ж характеристики, що й раніше (ACID, SQL), але запозичили багато фітчи з NoSQL технологій, щоб мінімізувати технологічне відставання:

  • Реплікація
  • Шардінг (масштабування)
  • Покращена ефективність для великих обсягів даних

Найбільш яскравий приклад в цій категорії — Google Spanner (колишній проект Google BigTable).

Тепер давайте познайомимося з найбільш популярної категорією NoSQL — document-store, яка дозволяє зберігати дані довільної структури (schema-less) як колекцію документів.

Що таке документ? Використовуючи реляційні бази даних, ми звикли до того, що наші дані зберігаються в таблицях як рядки. У таблиці фіксований список стовпців і в кожному рядку зберігається певне значення для будь-якого стовпчика. Такий підхід з часом призводить до того, що список стовпців все більше і більше розширюється для підтримки нових фітч. Кількість стовпців може досягти 100-200 і навіть більше. Але, по суті, тільки невелика частина стовпців використовується, а для інших зберігаються дефолтні значення. В результаті структура таблиці стає неоптимальною. Рефакторинг (нормалізація) в такій ситуації проводиться рідко через труднощі міграції. Документ зберігає дані в певному форматі (найчастіше JSON, але може бути і XML), тому тут немає певної схеми даних, і в кожному документі ви записуєте тільки ті поля, які містять непусті/не-null значення, таким чином, економлячи місце. В силу гнучкості JSON формату документи можуть містити не тільки поля з примітивними значеннями, але і вкладені документи, масиви і навіть JavaScript код.

Які технології з цієї групи зараз популярні і затребувані?

  • MongoDB
  • Couchbase
  • Amazon DynamoDB
  • Microsoft Azure Cosmos DB
  • CouchDB

Якщо ви не розглядаєте хмарні СУБД для хмарного проекту (DynamoDB і Cosmos DB), то серед інших трьох вибір очевидний — це MongoDB. Це не тільки найпопулярніша document-store технологія, але і сама використовувана NoSQL база даних.

Розробка цього амбітного проекту почалася в 2007 році компанією 10gen (2013 році перейменовану в 2013 році в MongoDB Inc), яку заснував американський програміст Дуайт Мерриман. MongoDB був його не першим проектом, але найуспішнішим. Перший публічний реліз відбувся в 2009 році, і з тих пір Mongo є флагманом NoSQL сховищ даних, включаючи чотири видання:

  • Community Edition — для навчання, тестування, локальної розробки і невеликих проектів. Це єдина версія, для якої є офіційний Docker image.
  • Enterprise Edition — включає in-memory storage engine, додаткові засоби безпеки і шифрування
  • Atlas — хмарний сервіс, доступний в AWS, Google Cloud, Azure і т.д.
  • Stich — serverless версія для мобільного і веб-розробки, коли ви можете звертатися до бази даних безпосередньо з JavaScript коду

MongoDB зберігає дані як JSON-документи, але в більш оптимальному і компактному форматі — BSON (бінарний JSON). BSON не тільки економить місце, але і за допомогою свого парсеру дозволяє зробити часткову зміну документа. Якщо для того, щоб змінити JSON документ, вам потрібно його спочатку повністю прочитати, змінити і потім зберегти, то BSON парсер може звернутися і змінити будь-який шматок документа, що скорочує загальний час операції.

Чи можна запхнути всі дані в один документ? На жаль, але в MongoDB є обмеження на розмір одного документа — 16 Мб. Така межа цілком обгрунтована. Для прискорення роботи MongoDB намагається зберігати часто використовувані дані в пам’яті. А так як документ являє собою єдине ціле, то і завантажуватися він буде цілком і займати пам’ять.

Як бути з бінарними даними (картинки, відео, аудіо)? Хоча BSON підтримує байтові масиви, але зберігати мультимедіа в документах вкрай не рекомендується через тих же обмежень. Для цього є спеціальний GridFS API, який дозволяє зберігати великі бінарні файли. Ці файли зберігаються не монолітно, а розбиваються на шматки (chunks) по 256 кб.

Наскільки безпечно використовувати MongoDB, якщо він зберігає частину даних в пам’яті? Що буде в разі апаратного збою? Для доступу до даних MongoDB використовує storage engine, який може бути трьох варіантів:

  • MMAP (оголошений deprecated в версії 4.0)
  • WiredTiger (з’явився в 3.2)
  • In-Memory (доступно тільки для Enterprise Edition)

Тому для MongoDB 4 дефолтний движок — WiredTiger, який привніс багато цікавих фітч (мульти-документні транзакції, стиснення даних, блокування на рівні документа). Всі операції, які змінюють дані, зберігаються в спеціальному журнальному буфері, який зберігається в пам’яті. Кожні 100 мілісекунд вміст буфера синхронізується з журналом, який вже зберігається на диску. Кожні 100 секунд в журналі створюється контрольна точка (checkpoint), коли виконуються всі операції після попереднього checkpoint, і дані зберігаються на диск. Якщо протягом цих 100 секунд стався збій, то після рестарту сервера WiredTiger виконує всі операції, збережені в журналі після останнього checkpoint.

Чи підтримує MongoDB транзакції? Чи може вийде так, що якийсь документ збережеться частково? В цьому плані Mongo змінює документи атомарно. Незалежно від вмісту документа, ви завжди можете бути впевнені, що операція зміни завершиться успішно, або відкотиться. У MongoDB 4 на прохання розробників нарешті додали мульти-документні транзакції, які нам відомі по реляційним СУБД. Реалізацію ускладнювала наявність такої функціональності як реплікація і sharding, але все ж і підтримка sharding cluster була додана в версії 4.2. Правда, з кількома обмеженнями:

Ви не можете створювати колекції в рамках транзакції

  • Таку транзакції можна здійснювати тільки на Mongo сервері, що входить в кластер для реплікації (нехай і з одного вузла)

Як ви бачите, в MongoDB є і свої переваги в порівнянні з реляційними СУБД, але вони вимагають зовсім іншого підходу на проектування та керування вашими даними.

👍НравитсяПонравилось12
В избранноеВ избранном8
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

MPP автор где потерял?

Якщо хтось ще не бачив цей старий «мульт» про MongoDB, то ДУЖЕ рекомендую: www.youtube.com/watch?v=b2F-DItXtZs

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

Я не пойму чего все дрищут на монгу.

Бо раніше було занадто багато дрочби на монгу. От реально на початку десятих було дуже модно юзати всякі ruby on rails і mongodb.

Это же очередной интсрумент, со своими свойствами, если не подходит, возьмите другой.

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

Этому ролику про монгу уже больше 10 лет.

Шерлок, це ти?

Так я таких и дотнетеров видел и сишников, кого угодно. У всех тулзов/языков были/есть фанаты. Некоторые джависты до сих пор на js гонят вместо того чтобы просто понять его, принять к сведению и спокойно пользоваться. Это всё вавки в голове, но не в монге.

Так я таких и дотнетеров видел и сишников, кого угодно.

Та ладно? Є деякі технології, які ніхто не хвалить (php), є деякі технології, якими дофіга народу користується, але всерівно не хвалить (C++), є деякі технології, якими користується чуть-чуть людей але шуму від них 90%, наприклад, все AI/ML, BigData і BlockChain. Так от ... монгери з тих, від кого на початку десятих було ДОХУЇЩА шуму.

Это всё вавки в голове, но не в монге.

Може бути, але вони не просто так беруться. Я он PHP трохи поюзав і досі PTSD.

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

А потом Риддик грохнул Лорда Маршала и стало более-менее... :)

Я не пойму чего все дрищут на монгу.

потому что их sql мучил, пытал, утюгом горячим, иголки под ногти загонял

и теперь — вот она, свобода и счастье!

Дякую всім за коментарі. Я з них почерпнув багато корисного з вашого практичного досвіду.

Чому це в монго немає транзакцій?

Ось типова реалізація на Go:

import (
	"errors"

	"go.mongodb.org/mongo-driver/bson"
	"go.mongodb.org/mongo-driver/mongo"
	"golang.org/x/net/context"
)

	session, err := db.Client.StartSession()
	if err != nil {
		return err
	}
	err = session.StartTransaction()
	if err != nil {
		return err
	}
	err = mongo.WithSession(ctx, session, func(sctx mongo.SessionContext) error {
	
		... Робота с транзакціями через sctx ...
		
		error - sctx.AbortTransaction(sctx)
		success - session.CommitTransaction(sctx)
	})
	session.EndSession(ctx)

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

Однак, тут я вважаю, що зараз немає конкуренції між SQL та NoSQL, це взаємодоповнюючі технології, той же Postgres працює, приблизно, з обома.

той же Postgres працює, приблизно, з обома.

WUT?

Краще дайте лінк на оригінал, а не на переклад

www.postgresql.org/...​cs/9.6/datatype-json.html

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

jsonb є тип даних для postges

Про які два підходи мова йде?

Додавання json-field не змінює підходу постгреса до транзакцій

Якщо ви порівнюєте EAV vs JSON-field, то краще це вказувати

я просто хотів сказати, що зараз немає конкуренції

справа не у конкуренції, а в оманливості надій що технологія X вирішить проблеми, які вона вирішувати не вміє :)

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

В общем, до продакшена в серьёзных вещах (медицина, финансы, автомотив, итп) — nosql не доживает.

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

Если сложная структура данных — никто это изначально на nosql делать не будет.

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

обычно указание к применению хранения «в документе» — ничего кроме текстового поиска к его содержимому применяться не будет.

а как только возникает потребность отбора этих документов по содержимому, с условиями не только на равенство, и каждая лексема там значима, тогда и — «поговорим об удобствах NoSQL» :)

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

Ви ним користувались в реальних проектах?

Коли я користувався, то було швидше видрати все і вже в пітоні формувати потрібні колекції

І якщо з реальними noSQL я ще розумію нащо воно мені, то з монгою такого відчуття не було

Не понял Вас, честно говоря. Там есть все типичные операторы сравнения и т.п., разве что (говоря про .NET драйвер) с проекциями уже далеко не так удобно, как в EF Core ORM’ке, к примеру. Может, под Вашу платформу просто драйвер слишком неудобно реализован — не знаю...

восторги монгой затихают как только появляется понимание что в бд нужно не только писать, но и читать от туда
весьма тривиальные для реляционных бд запросы на монге выливаются в головную боль.
из того что я наблюдал по монге в реальном проекте — писали в монгу, все что нетолерантно к задержкам читалось из нее же. Паралельно работала апликуха которая из монги данные выкачивала в DWH на реляционной субд (SQL Server если быть совсем точным). на DWH потом и ложилось основное количество операций чтения.
ну и народ там потом сказал «Монго? Никогда больше». Некоторые проекты начали на PostrgeSQL делать, остальное как и раньше на SQL Server.
самое смешное, что монгой тогда решали высосаную из пальца проблему масштабирования (типа придет к нам много-много клиентов и нам придется писать много много данных), типа упираемся в потолок производительности — ставим еще ящик шардированый с монгой.
Уже позже занимаясь неестественным сексом с монгой народ понял — что в общем и на SQL Server можно было очень сильно ускорить существующие процессы если грамотно поменять архитектуру, распаралелить некоторые задачи и т.д. поэтому часть фукционала получилась на монге, а часть осталась на SQL Server (решили что переносить на монгу — себе дороже будет).
Виной всему тому цирку был прости господи «архитектор» — POCи делал весьма однобокие в которых упор был на запись данных, чувак свято верил что монга серебрянная пуля которую модно впихнуть в любой проект и будет счастье.
мое субъективное мнение про монгу — абсолютно нишевый инструмент. Если вы попадаете в эту нишу и у вас есть ГРАМОТНЫЙ архитект/разработчики способные грамотно это все реализовать — у вас есть хорошие шансы на успешную историю. В противном случае лучше — воспользуйтесь одной из реляционных СУБД.

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

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

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

Стата на великих рекламних мережах

Юзкейс, коли клієнту не треба точна стата секунда в секунду

что быстрее будет

В файл пачкою, звісно xD

Ні, я проти використання монги
xD

Для мене монга більше схожа на девнулл ніж файл

¯\_(ツ)_/¯

В файл пачкою, звісно xD

Я это имел в виду. /dev/null — Очень жирный и быстрый файл)

Для мене монга більше схожа на девнулл

А это часто с no sql, меряются скоростью вставки, а самое интересное часто оставляют за кадром ¯\_(ツ)_/¯

Это не проблемы документоориентированной базы, а проблемы Монго. Что мешало обычный sql прикрутить. Документ по сути заджойненные данные.

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

если бы язык запросов соответствовал скорости выдачи этих хитровывернутых запросов — то да.

но соответствия то нет :)

то что монговский запрос по сути соответствует SQL ни о чем не говорит.

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

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

То есть, если бы все синьоры хорошо знали SQL ты бы выбирал SQL?

*не sql, а що таке Третя нормальна форма

що таке Третя нормальна форма

Когда неключевые колонки зависят напрямую от ключа, а не от других неключевых колонок.
Та любой нормальный синьор все 10 форм за выходные выучит(я так недавно сделал). Не понимают в чем тут проблема вообще.

Це вимагає зусиль
А нащо їх прикладати, коли «ти вже досяг стелі» xD

за выходные выучит

В ВНЗ на курсі теорія бд

только перед очередным собесом

Та любой нормальный синьор все 10 форм за выходные выучит(я так недавно сделал).

И за следующие 2 дня забудет. Потому что всё что выше 3-ей — это маразм. Всё что ниже — вообще не поддаётся чёткому определению, приходится объяснять в каждом конкретном случае, чем именно пришлось жертвовать по сравнению с 3 формой.

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

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

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

ниразу в жизни не использовал

это такой себе аргумент, но аргумент....

Нообычно на терабайтах данных все запросы до 100мс.

Якщо ви здатні руками самостійно на терабайтах утримувати ACID і не втрачати дані, то ви маг і чародійник (в гарному сенсі)
Але це вимагає від всіх хто поряд з вами пише — бути такими ж

когда микросервисы везде

nope
Це може бути в вашій області, але це точно не всюди

Якщо ви здатні руками самостійно на терабайтах утримувати ACID і не втрачати дані, то ви маг і чародійник (в гарному сенсі)
Але це вимагає від всіх хто поряд з вами пише — бути такими ж

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

nope
Це може бути в вашій області, але це точно не всюди

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

Те, кто мыслит выборками из бд для них мой подход кажется тупорылым :)

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

когда микросервисы везде

совсем не везде.
мало того, хайп о них сходит не один год.

Нообычно на терабайтах данных все запросы до 100мс.

ну, может на террабайтах и по 100мс
только что это за проекты — где такие размерчики данных :)
геоданные собирают?

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

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

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

на терабайтах

только что это за проекты — где такие размерчики данных :)

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

В ноускл уходят не от хорошей жизни.
Но у вас почемуто ноускл = «бложик»

ну, может на террабайтах и по 100мс

интересно, как вы поняли что тут имеется в виду?
фраза звучит как в анекдоте:
— Приборы?
— 300
— что 300?
— а что приборы?

без конкретизации того что имеется в виду под «всеми запросами» сложно сказать 100мс это хорошо или плохо

NoSQL цілком може використовуватися як додаткова БД, де зберігатимуть наприклад кеш (Redis) або аналітику (Cassandra).

Пока вроде не постили: как на самом деле работают транзакции в MongoDB.

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

Хорошие подробности. Вообще в технических холиварах вера в чудеса у колег поражает.

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

А чего не запостил что это уже починили давно?

Что «это» починили? Когда «уже давно»? Не умею читать мысли, знаете ли.

Это jepsen.io/analyses/mongodb-4.2.6 починили, уже около года как. Умей следить за цепочками которые сам создал.

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

Читал еще год назад. Там про баг jira.mongodb.org/browse/SERVER-48307 Остальное не проблема, а нытье тех кто привык к МССКЮЭЛ и тому как это сделано там и теперь им кажется что везде дожно быть так. Нужно понимать что всё разное сделано по разному. А не выучив молоток думать что теперь всё везде гвозди и другого не бывает. Свои советы по воспитанию оставь себе и для своих детей.

В самом начале статьи написано про фикс, но надо врываться с «гениальными» требованиями ко мне вместо того, чтобы быть внимательнее.

Свои советы по воспитанию оставь себе и для своих детей.

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

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

1) тим, хто працюєте з БД використовуючи підхід Code First.

Багато сучасних програмістів не вміють проектувати реляційні БД, не вміють писати більш-менш складні SQL запити та Stored Procedures. Все що їм потрібно — покласти об’єкт (список обєктів в БД), взяти об’кт (список об’єктів ) з БД. Те, що ORM генерує при цьому дуже неефективні запити, не проблема — докинемо потужності на сервер БД і все буде нормально. В таких випадках монга може бути ефективнішою ніж реляційна БД.

2) у випадку стартапу або проекту, де вимоги спочатку не до кінця зрозумілі або замовник їх часто змінює та доповнює (або і те й інше одночасно).

На моєму поточному проекті структура БД більш-менш стабілізувалася більше ніж через півроку після початку використання в продакшені. І все одно дрібна міграція присутня майже при кожній новій поставці. Просто раніше міграції могли суттєво міняти структуру даних, а на даний момент це як правило дрібні зміни.
З моєї точки зору, flexebility і changebility монги значно вища ніж в реляційних БД і трудозатрати на складну еволюцію БД при використанні монги суттєво менші.

3) у випадку мікросервісної архітектури.

Мікросервіси містять окремі, як правило невеликі БД. Загальна цілісність даних системи забезпечується спеціальними патернами і підходами, котрі можуть бути використані і для монги. При цьому структура даних часто дуже гарно лягає на документо-орієнтовний підхід, коли БД мікросервіса містить одну чи кільки колекцій з однотипними ієрархічними структурами. Це якраз те, для чого потрібна монга.

4) якщо Ви спробували використовувати монгу і Вам дуже сподобалося :).

Про що потрібно пам’ятати перед тим як почати використовувати монгу:

1) Пошук по РСУБД як правило швидший. Звичайно якщо писати нормальні SQL запити.
2) Майже всі сучасні РСУБД мають тип поля JSON, по якому можна виконувати досить складний пошук.
3) У випадку більш-менш складних систем при використанні монги потрібно вміти робити дизайн БД. І мати на увазі що проектування БД на основі монги відрізняється від проектування реляційних БД, інколи суттєво.

І останнє. Рекомендую почитати коротке порівняння PG і монги від Peter Harrison (там більше саме про сенс використання монги).
dev.to/cheetah100/comment/pj75
Погоджуюсь майже з усим ним викладеним.

Додайте трохи води і перепостіть як статтю

А що, так можна?
П.С. Якщо серйозно, то нормальна статя на таку тему повинна включати хоча б якісь діаграми, порівняння реляційної БД з таблицями і монги з колекціями. Можливо приклади запитів. Якщо буде час та натхнення то зроблю.
Дякую за пораду.

Багато сучасних програмістів не вміють проектувати реляційні БД, не вміють писати більш-менш складні SQL запити та Stored Procedures.

так, це одна з головних причин.

Все що їм потрібно — покласти об’єкт (список обєктів в БД), взяти об’кт (список об’єктів ) з БД.

так, БД, частенько використовуються просто як key-value storage незалежно від їх типу.

2) у випадку стартапу або проекту, де вимоги спочатку не до кінця зрозумілі або замовник їх часто змінює та доповнює (або і те й інше одночасно).

залежить від домена.
вимоги ж змінюються завжди. і не в стартапах.

З моєї точки зору, flexebility і changebility монги значно вища ніж в реляційних БД і трудозатрати на складну еволюцію БД при використанні монги суттєво менші.

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

у випадку мікросервісної архітектури.

тут повністю згоден.
чимала кількість мікросервісів у тру микросервісній системі не потребує нічого крім key-value storage.

Про що потрібно пам’ятати перед тим як почати використовувати монгу:

головні ж противопоказання до неї

цінність зберігаємих данних — у числах.
причому числа ці являються характеристиками об’єктів домену.
і їх значення є повністю відповідними до характеристик об’єктів матеріального світу
і пошук головним чином робиться на порівняннях чисел між собою
і їх зміна — конкурентна

Приклад
Маємо ресурсу 5 одиниць.
Хочуть придбати цей ресурс 10
Але тільки у 6ьох є гроші на рахунку системи для придбання цього ресурсу

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

Звичайно багато в чому доцільність і ефективність використання монги залежить від домену. Але щодо гнучкості і змінюваності ІМХО монга все ж виграє. Доводилося розвивати проекти і робити міграцію як з використанням РСУБД так і монги. Трудозатрати на такі речі з РСУБД більші в рази. Хоча це все досить суб’єктивно.
Щодо розміру швидше погоджуся, але якщо мова про кількість записів/документів до мільйона (мільйонів) і міграція не є якоюсь надскладною то різниця в швидкості не суттєва.
Також варто зазначити, що монга це не просто key-value storage. Крім реплікацій і шардінгу монга підтримує повноцінні secondary indexes та транзакції, а також розвинену мову запитів як на оновлення так і для читання. Тому має деякі перевали перед іншими noSQL якщо ви переходите з РСУБД.

та транзакції,

С версии 4.0.
Прошло каких-то 12 лет чтобы осилить транзакции монгописцами.
И то, осилили далеко не все виды которые там должны быть (по сравнению с рсубд)
Пройдет еще какихто 10 лет и откажутся от лимита в 16мб на документ.

1) «Не только лишь все» noSQL DB реалізували транзакції. Я знаю про дві такі: RavenDB та MongoDB. Можливо з’явилися ще якісь, давно не цікавився питанням. В будь-кому випадку, монга одна з небагатьох. Мабуть реалізувати ACID транзакції при повноцінному шардінгу задача нетривіальна.
2) З самого початку монга проектувалася як набагато більш примітивна БД, задачу про транзакції ніхто не ставив.
3) В РСУБД також 5 років тому не було типу поля JSON. А тепер там такий складний і швидкий пошук по JSON що рання монга позаздрить. Все тече і змінюється. NoSQL намагається взяти найкраще з реляційних БД і навпаки.
У Вас просто якийсь песимістичний погляд на монгу :).

У Вас просто якийсь песимістичний погляд на монгу :).

У монги задача, показать что документоориентированная модель жизнеспособна.
А так, за ней пойдут намного более совершенные СУБД ;)

Доводилося розвивати проекти і робити міграцію як з використанням РСУБД так і монги. Трудозатрати на такі речі з РСУБД більші в рази. Хоча це все досить суб’єктивно.

dynamic typing vs static typing

якщо немає схеми — то тоді зміна формату данних буде відображена у запитах
якщо треба вся історія — то у коді будуть запити на всі «міграції». для кожної версії

Також варто зазначити, що монга це не просто key-value storage.

я цього й не казав.
а казав що частенько любу БД використовують як просто key-value storage.

Крім реплікацій і шардінгу

так. бо данні незалежні.

а також розвинену мову запитів як на оновлення так і для читання

такі мови були ще в базах 60их років.

та транзакції

я читанув доку
docs.mongodb.com/...​ite-operations-atomicity
та docs.mongodb.com/manual/faq/concurrency

там багато цікавого.
наприклад табличка у
The following table lists some operations and the types of locks they use for document level locking storage engines:
якось дивно схожа на такі ж у РСУБД, але
Це призводило до різного роду складнощів і обмежень:
Блокування рядків/таблиць/схем під час транзакцій

Я думаю нам нема про що сперечатися :).
Так, монга поступається мовою запитів більшості РСУБД, але в порівнянні з іншими noSQL DB мова запитів у монзі крута і по-своєму унікальна, адже майже нічого спільного з SQL не має.
Так, транзакції у монги не настільки надійні і продвинуті як у РСУБД (підтримується тільки рівень ізоляції snapshot, є дослідження, що при певних обставинах транзакції монги працюють не так як очікує користувач), але як для noSQL DB і це майже унікальне досягнення.

В будь-якому випадку, ІМХО, монга варта того щоб при певних умовах розглядати її як заміну РСУБД.

Справа не у мові запитів.

А в тому що забувається що в компьютері тільки байти.

І виникає нерозуміння що такє документ, об’єкти, типи і т.і.

Монга з народження не вміє у транзакції. так вона спроектована — не вміти цього. Бо вони не були потрібні.

А як зазначив DNA Еxp їх не вийде додати потім,без радикальної зміни роботи з отими байтами.

Є такі речі,і на більш вищих рівнях абстракції

А тепер автори пробують їх втулити -бо купа проектів підсіла, на отому хайпі, і виявилося що потрібні.

Історія розвитку айті то ніяка не математика, і зазвичай отака іраціональна.

А монга піде у напрямку що й реляційні бд.
Бо варіантів дій на байтами у комьютері -небагато

Виникнути нерозуміння може тільки якщо погано вчити.
Я про байти в монзі читав в цій книжці www.yakaboo.ua/...​a/mongodb-v-dejstvii.html це 7 років тому. Зараз вже вийшло перевидання, і мабуть вже не одне.
Там описують в тому числі і базові речі, і байти і файли і т.п.

Втулили транзакції не так через те що проекти на хайпі підсіли, а більше тому що акції монги торгуються на біржі і поява транзакцій повинна була підвищити капіталізацію (перша noSQL DB з транзакціями і оце от все). А у топ-менеджмента був план по підвищенню тої капіталізації.

А куди прийде монга — поживемо-побачимо.

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

згоден. ця причина може бути вагомішою за мою версію про «підсіли».

Виникнути нерозуміння може тільки якщо погано вчити.

є три стадії вивчення чогось (принаймі перші)
зазубрив
вивчив
зрозумів

А куди прийде монга — поживемо-побачимо.

нема куди йти.

Є байти.
і дві дії:
читаємо-змінюємо
І у байтів є адреса. за якою проц робить ці дії. Немає значення подробиці як то вона формується.
Та й немає значення який саме проц. центральний, чи у конролері.

І нема ніяких з цим проблем покі і читає і пише — один.
Процесс, потік, — що завгодно.

А от як вже двоє — то чиї зміни — нам зберегти?
Коли є визначена послідовність — теж немає. Хай ціх змінючих хоть скільки буде — по визначенній черзі змінюють та й все буде добре.

А як та черга — невизначена, випадкова?

Сам отой байт — то конкуретний ресурс.

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

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

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

а воно було так спроектовано. бо втрата коменту чи лайку — э некритичною для деяких систем.
далі можна і про CAP, і т.д.

головне що — нема куди йти.

А мова запитів — то взагалі зовсім про інше.
ніякого відношення до варіантів вирішення не має. хоч англійська, хоч китайська.

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

у комп’ютера тільки байти, та послідовність їх зміни

у комп’ютера тільки байти, та послідовність їх зміни

В комп’ютері — так. А в software engineering є тільки гроші та послідовність перетоку цих грошей від одного суб’єкта до іншого. От з точки зору грошей і варто розглядати монгу. І тут у неї є куди йти.

От з точки зору грошей і варто розглядати монгу

???

1) Чи дає монга можливість більше заробляти/економити на деяких проектах у порівнянні з РСУБД чи іншими noSQL DB? За допомогою хайпу, за допомогою реальних технічних перевах, за допомогою чогось іншого? Думаю так.
2) Чи є куди рости акціям монги на ІРО? Думаю так.

1. Nope
2. Є безліч перепроданих акцій

Гроші не можуть вирішити логічні проблеми. Або збільшити кількість варіантів її вирішення

так, БД, частенько використовуються просто як key-value storage незалежно від їх типу.

тут прямим конкурентом буде Redis (він ін меморі)

Чомусь замість реальних працюючих noSQL DB люди розказують про монгу

Мабуть тому, що монга найпопулярніша noSQL DB (№ 5 серед усіх БД всіх типів). Редіс правда потихеньку підбирається і прилаштовується ззаду (№ 7).

Спасибо за пост!

2) у випадку стартапу або проекту, де вимоги спочатку не до кінця зрозумілі або замовник їх часто змінює та доповнює (або і те й інше одночасно).

На моєму поточному проекті структура БД більш-менш стабілізувалася більше ніж через півроку після початку використання в продакшені. І все одно дрібна міграція присутня майже при кожній новій поставці. Просто раніше міграції могли суттєво міняти структуру даних, а на даний момент це як правило дрібні зміни.
З моєї точки зору, flexebility і changebility монги значно вища ніж в реляційних БД і трудозатрати на складну еволюцію БД при використанні монги суттєво менші.

Можете плз объяснить, как это происходит на практике?
1. Данные абсолютного большинства проектов, так уж сложилось, реляционные по своей природе. Потому что бизнес — он почти всегда об отношениях между сущностями. И, если Ваши данные хаотичны и Вы пока не знаете, какая схема получится, то есть большой, нет, даже ОГРОМНЫЙ шанс того, что они в итоге окажутся реляционными (даже в пределах одного микросервиса, т.к. high cohesion — это мастхэв при хорошем проектировании). Поэтому я бы наоборот советовал брать сиквел, если Вы ни в чём не уверены.
2. По поводу преимущества слабой схемы именно NoSQL’а. Если Вы сломаете обратную совестимость, то как потом работать с обработкой этих данных, т.е. кодом?
2.1. Поддерживать 100500 версий схемы (классов)? Не вижу лёгкости.
2.2. Парсить все документы по отдельным полям? Аналогично лёгкости нет.
2.3. Поддерживать постоянно только одну версию и делать кастомные миграции данных в случае обратной несовместимости? В таком случае в чём отличие от сиквела?
2.4. Оставлять обратную совместимость? Сиквел тоже умеет в NULLable колонки.
2.5. ?

А, и да, если у Вас всё так хаотично, то микросервисы 90% отпадают, т.к. это взаимоисключающие факторы: если сабдомены перетекают друг в друга, то всю систему придётся постоянно перепроектировать (bounded context должны быть очень чётко определены), и тогда легче застрелиться)). Либо оставлять всё с кривой архитектурой.

Я не зовсім зрозімів Ваше друге запитання, але спробую відповісти.

1) Мені здається це стереотип. При використання якоїсь мови ООП ми думаємо що дані по природі ієрархічні, при роботі з РСУБД — що реляційні. Дані по своїй природі різні, в якій моделі їх ефективніше зберігати і обробляти залежить від багатьох обставин.
І звичайно high cohesion (і low coupling) — мастхев. Але мені не зрозуміло, чому це не можна забезпечити в монзі? Нема foreign keys і якихось інших констреінтів? Це не перепона при нормально проектуванні. Посилатися з однієї колекції на іншу ніхто не забороняє, джоінити через lookup можна. Єдина потенційна проблема — швидкість таких запитів.
Але хочу ще раз підкреслити — проектування в монзі суттєво відрізняється від проектування в реляційних БД. Тому часто замість посилать однієї колекції на іншу варто об’єднувати різні сутності в одну колекцію документів.
Є певні правила проектування монги, які не настільки розвинені і формалізовані як для реляційних БД, але вони дозволяють забезпечвати high cohesion і все інше.
Подивіться невеликий допис, посилання на який я вже наводив: dev.to/cheetah100/comment/pj75
Там якраз розповідається, що не можна використовувати монгу так, як використовують РСУБД.

2) Тут Ви мабуть ставите запитання виходячи з особливостей Вашого проектування бекенду і технологій які Ви використовуєте.
На даний момемнт для реалізації бекенду я використовую nodeJS і нещодавно почав Golang для деяких мікросервісів. Ви пишете на .NET
І хоч в мене є 10-річний досвід використання .NET, я не зовсім розумію про що Ви.
Навіть при статичній типізації, якщо ми працюємо з об’єктами, котрі є контейнерами даних, в чому полягає проблема зворотньої сумісності?
Для чого тримати 1000 версіх класів?
Для чого парсити по окремим полям?
Якщо Вам не важко, опишіть будь-ласка проблему ще раз, можливо з прикладами, і я спробую відповісти.

Наприклад, у Вас моноліт, кілька різних Bounded Context, після міграції потрібно підтримувати попередню версію Вашого REST API для таких-то контекстів, при цьому маємо такі то проблеми.
І т.д.

Можливо я занадто довго пишу мікросервіси і давно не користувався нормальною ООП мовою. Але після більш детального пояснення проблеми думаю зможу відповісти.

При використання якоїсь мови ООП ми думаємо що дані по природі ієрархічні, при роботі з РСУБД — що реляційні. Дані по своїй природі різні, в якій моделі їх ефективніше зберігати і обробляти залежить від багатьох обставин.

Не согласен. User / Blog Post / Comment. Всего три типичные энтити, и уже не иерархия, уже relation. При желании таких примеров можно придумать очень много из разных областей. А в любом бизнесе сущностей десятки, а то и сотни, что практически неизбежно приводит к реляционности. Шанс того, что в микросервисе получится обойтись редкими lookup’ами, очень сильно меньше, чем перспектива иметь lookup’ы везде, если выбирать только Монгу, т.к. она для такого использования не предназначена. И т.о. опять возвращаемся к сиквелу. Плюс высокий уровень вложенности документа бьёт по перформансу в случае частых апдейтов, поэтому тоже не разгуляешься с иерархичностью.

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

Как плюс Монги выше указывается слабая схема, и что при хаотично меняющихся данных — это гораздо лучше, чем сиквел. Я перечисляю случаи, когда разницы с сиквелом на практике нет (когда остаётся обратная совместимость), и что разница теоретически будет только при обратной несовместимости. Но всё же мне непонятно, чем на практике лучше Монга со слабой схемой даже при обратной несовместимости, если и с ней, и с сиквелом будет проблема поддержки схемы на стороне аппликейшена и кастомной миграции данных? Справедливости ради да — я смотрю с точки зрения .NET, где миграцию сиквел схемы за меня сделает ORM.

Подивіться невеликий допис, посилання на який я вже наводив: dev.to/cheetah100/comment/pj75
Там якраз розповідається, що не можна використовувати монгу так, як використовують РСУБД.

Сорри, ИМХО там вода и нет конкретики. Пишу именно со своего опыта переезда монолита на микросервисы и самостоятельного проектирования и сиквела, и документо-ориентированной БД. И в моём случае он чётко показал ограниченность использования последних в типичных проектах — данные сабдомена гораздо чаще под них не подходят, чем подходят.

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

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

Я в этом предложении про Монгу и только про неё). Мы в Монге с этим столкнулись на практике. Уже в 4й версии (может, в последних минорных версиях они это изменили, не знаю).

Ужасы про джойны — это по большей части бабушкины страшилки.
Потому джойнов никаких нет.

Есть позиционирование на нужные байты.
И все зависит от количества операций для этого

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

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

Если у вас все в память влезло, отключите диск. Нечего там читать. На практике LRU кеш работает слегка с меньшим оптимизмом чем у вас.

Если у вас все в память влезло

горячие данные обычно влезают

когда не влезают — расположение байтиков на диске уже мало поможет

работает слегка с меньшим оптимизмом чем у вас.

у нас да, массово.

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

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

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

Не согласен. User / Blog Post / Comment. Всего три типичные энтити, и уже не иерархия, уже relation

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

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

Стопицот комментов под постом никакой пользователь не прочтёт. Поэтому нет смысла выдавать их сразу все — избыточно читать, передавать и отрисовывать.
Это — удар по перфомансу

В монго (и Днипро) есть проджекшин.
Тоесть запрос который возвращает не весь док

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

например
есть тема, с комментами в ней одним документом (комменты в нем же)

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

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

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

а «джойнов никаких нет», потому что в действительности это тоже where
где-то читал что в версиях оракла до какого-то их не было даже на уровне синтаксиса :)
потому что — where это, на кой этот синтаксический сахар :)

а что такое where в компьютере?

цикл, перебор.
у нас есть коллекция, массив, по которой надо пройтись, и сравнивая каждый элемент по какому-то условию — получить true/false

индексы, ключи, и прочая — ничего принципиального в этот перебор не вносят.

а теперь поясните, как достигаются чудеса перфоменса
при

Сканируешь сабкластер ключей по префиксу

вместо «заджойнил по проиндексированному полю»

а теперь поясните, как достигаются чудеса перфоменса
при

Сканируешь сабкластер ключей по префиксу
вместо «заджойнил по проиндексированному полю»

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

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

Для этого нужно понимать как работает trie.

нет.
вначале надо с байтиками разобраться, как они работают
специально глянул:
Конкретно у нас:
браузер показывает что лог в 10мб отдается за 296мс
потому что такой фреймворк, в дебаг режиме, такой канал у хостера, и т.д. и т.п.
а байтики лога лежат на SSD, (рядышком? я хз), и на сервере даже наверняка в кеше файловой системы, CTRL-F5 сделал несколько раз :)

И вы просто спускаетесь по иерархии и открываете нужную папку.

никуда вы не спускаетесь.
есть проц, озу и байтики.

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

но байтики на диске, когда они уже в ОЗУ — ни ап чем

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

инет полон синтеческих тестов.

особенно классные тесты где foreach на миллиарды выполняется мгновенно
потому что автор теста не в курсе что компилятор (статический или рантаймовый) выбросил его весь, видя что у него, у цикла этого никакого полезного выхлопа :)

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

тот же json в марийке — делаются вирт персистентные поля с индексом по ним и джойнь себе

Это не ваша вина, просто нет времени объяснять.

та это понятно что вас никто не понимает :)

с гениями частая история.
потому что они никого не понимают :D

особенно классные тесты где foreach на миллиарды выполняется мгновенно
потому что автор теста не в курсе что компилятор (статический или рантаймовый) выбросил его весь, видя что у него, у цикла этого никакого полезного выхлопа :)

Я понял ваш уровень дискуссии.
Рад что принял решение с вами больше не дискутировать.

Я понял ваш уровень дискуссии.

ваш понятен давно, как старожил доу вы у меня в списке непризанных гениев :)

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

Вообщето индекс дерево. Еще и в кеше обычно(даже не памяти) первые(самые используемые) куски.

Это называется B+ дерево. Это я учитывал оставляя коммент.

Вам нужно почитать что-то из того как работает конвейер процессора. Что такое L1 L2 кеши процессора и что такое cach miss. Не все данные в памяти одинаково полезны. И учитывая что среди всех ноускл решений рсубд считаются самыми медленными, то стоило бы догадаться, что кеш для рсубд тоже не очень.

Вам нужно почитать что-то из того как работает конвейер процессора.

я как бы смехотехник, по образованию, а не программист.

и если у вас все данные влазят в кеши процессора то да, круто!

Не все данные в памяти одинаково полезны

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

что кеш для рсубд тоже не очень.

кеши у рсубд бывают разные.

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

и такой же кеш у массы NoSQL баз.
так в чем же их чудо?

почему это они могут отадавать из ОЗУ байтики, при обращении по хешу к их набору, а вот рсубд с таким же кешированием — отдают ощутимо медленее? ;)

Не согласен. User / Blog Post / Comment. Всего три типичные энтити, и уже не иерархия, уже relation. При желании таких примеров можно придумать очень много из разных областей. А в любом бизнесе сущностей десятки, а то и сотни, что практически неизбежно приводит к реляционности.

Я не зовсім зрозумів з чим Ви не згодні. Я всього лише написав, що переваги ієрархічної чи реляційної моделі залежать від умов.
User / Blog Post / Comment можна реалізувати по різному. Якщо без додаткових деталей, то я би реалізовував юзерів окремою колекцією, пости теж окремою колекцією зі ссилкою в корені на автора посту, а коментарі массивом всередині документа Blog Post, також зі ссилкою на автора коментаря та з власним ІД і посиланням на батьківський коментар, якщо такий є. Така структура навіть при відносно великих об’ємах даних дозволила б писати ефективні запити. Коментарі прив’язані до поста, послідовність постів можна будувати вже на клієнті, а всі коментарі користувача до різних постів шукаються досить ефективно при правильній індексації.
При відносно невеликих об’ємах можна звичайно все тримати взагалі в одній колекції.
Багато що залежить від деталей бізнес-логіки — максимальна можлива кількість коментарів і їх розмір (якщо мільйони по кілька тисяч символів то така модель не підійде), якого типу пошуки ми повинні забезпечувати, по яких полях і т.п.
А взагалі, реляційність є неминучою тільки при певних досить специфічних умовах.

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

Якщо це лінійна вкладеність (об’єкт в об’єкті), то я з такою проблемаю мабуть не стикався. Якщо ми говоримо про вкладені масиви, то там складніше, можуть бути проблеми, але на великих об’ємах.
І всі ці проблеми вирішуються правильним дизайном БД.

Но всё же мне непонятно, чем на практике лучше Монга со слабой схемой даже при обратной несовместимости, если и с ней, и с сиквелом будет проблема поддержки схемы на стороне аппликейшена и кастомной миграции данных?

З моєї точки зору монга краща тим, що при складній еволюції БД міграція значно простіша. Там де при реляційні моделі потрібно створювати нові таблиці, міняти схему в інших, міняти різні форен кеї і констреінти в монзі достатньо оновити пару колекцій.
Щодо схеми на стороні аплікейшина, то в nodeJS ця проблема майже не стоїть, але і в .NET це буде легше з монгою при правильному дизайні БД і моделях даних в коді. Звичайно не завжди вийде співставляти один клас з однією колекцією, але взазв’язок коду бекенда і БД буде простішим в будь-якому випадку.
А ОРМ далеко не завжди може забезпечити необхідну міграцію. З цим я якраз тісно стикався. І доводилося писати вручну купу скриптів на десять екранів кожен для нормальної міграції. Це було правда давненько, в 2015-му. Можливо все змінилося, але якось сумніваюсь.

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

У мене також є свій достід і він говорить протилежне. Тут мабуть ми не знайдемо порозуміння бо якраз маємо різний досвід.

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

рахуємо relation у рішенні:

то я би реалізовував юзерів окремою колекцією, пости теж окремою колекцією зі ссилкою(раз) в корені на автора посту, а коментарі массивом всередині документа Blog Post, також зі ссилкою(два) на автора коментаря та з власним ІД і посиланням на батьківський коментар(три), якщо такий є

тобто, у такий простій задачі вже три relation
relation: the connection or similarity between two things:
The relation between the original book and this new film is very faint.

dictionary.cambridge.org/...​оварь/английский/relation

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

так, на мові з динамічною типизацією — теж саме :)
набагато легше рефакторити.

але, чого це вважається що static typing більш надійний?

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

Наприклад замінивши на синонім до relation
connection
relationship
association
link
correlation
correspondence

тобто, у такий простій задачі вже три relation

я описав мабуть дещо сумбурно і не зрозуміло.

relation у нас два, між двома колекціями. коментарі знаходяться в одному масиві, який є полем документу Blog Post і посилаються один на одного (по якомусь нашому власному внутрішньому ІД а не ІД монги) для того щоб їх можна було впорядкувати в ієрархію на клієнській стороні (на вебі наприклад). можна додати глибину в ієрархії для коментаря і підтримувати певний порядок розташування коментів у цьому спільному масиві для легшої побудови ієрархії на клієнті а також для порційного пошуку коментів.
а взагалі я хотів показати, що небовязково коментарі поміщати в окрему колекцію і необовязково вибудовувати фізичну ієрархію коментарів прямо в монзі. все залежть від умов.

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

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

так, я про це вже писав, бо:

це денормалізація, яка в монзі широко використовується.

саме так :)
так просто обов’язково робити, бо монга не заточена на роботу з нормалізованими данними

і поки у вас бложик — то все буде добре. і нема потреби у головняку з рсубд
так само як не треба писати на С скрипт, коли на bash все добре пишеться :)

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

я просто про:
вірування у чудеса з оперуваннями байтами
і що у монгі з’являються всі ті речі які і є «головняком» у рсубд. і якщо буде так і далі розвиватись, то будуть лунати прокльони за все те саме :)

а у рсубд теж не обов’зяково викорстовувати транзакції та можна виставити глобально
read uncommitted і все буде літати

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

Якщо це лінійна вкладеність (об’єкт в об’єкті), то я з такою проблемаю мабуть не стикався. Якщо ми говоримо про вкладені масиви, то там складніше, можуть бути проблеми, але на великих об’ємах.
І всі ці проблеми вирішуються правильним дизайном БД.

В том-то и дело, что не решаются они правильным дизайном БД, если Монга не переваривает такой workload. Т.к. там вопрос даже не столько в объёмах, сколько в workload’е (а именно — количестве апдейтов этих вложенных элементов — описывал ниже эту проблему).

Поэтому, в чём основной минус: Монга вроде как рассчитана на иерархичность, а по факту эта иерархичность очень ограничена, что сильно сужает область использования в зависимости от workload’а. В итоге:
1. Т.к. данные по своей природе по большей части реляционные, то получить юз-кейс, когда можно представить их в иерархическом и/или нереляционном виде шансов сильно меньше, чем наоборот. В трёх типичных сущностях у нас уже relation и нужен «правильный дизайн базы», а при увеличении кол-ва сущностей до реальных кейсов «правильный дизайн» уже может не сработать, т.к. окажется, что там везде одни lookup’ы на кверях.
2. При этом, если хотим хранить иерархию — нужно убедиться, что вложенные массивы не будут часто апдейтиться, иначе локи просадят перформанс. И чем больше уровней вложенности, тем сильнее это будет выражено.

Понимаю, что каждый остался при своём).

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

Можете дати посилання на статті, де це детально пояснюється і аргументується? Поки що я з цим твердженням не погоджуюся. ІМХО — оптимальність моделі зберігання даних залежть від різних умов. реляційна модель просто найрозвинутіша і найкраще теоретично обгрунтована.

а при увеличении кол-ва сущностей до реальных кейсов «правильный дизайн» уже может не сработать, т.к. окажется, что там везде одни lookup’ы на кверях

у мене досвід трьох великих проектів з використанням монги де все спрацьовує. я не можу стверджувати що монга скрізь буде краще для використання ніж РСУБД, але ІМХО точно є випадки, коли таки краща.

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

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

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

Поки що я з цим твердженням не погоджуюся. ІМХО — оптимальність моделі зберігання даних залежть від різних умов.

Не хранения, а сама природа большинства данных. Вообще даже не реляционная, а графовая, если уж на то пошло, но пока мы о реляционке vs документах). Я не спорю, что возможно сделать так, чтобы всё нормально работало за счёт денормализации и разбивки на коллекции, но чем больше это задействуется именно в случае фактического присутствия relation’ов (даже если мы решили от них избавиться с помощью технических решений), тем больше выглядит просто как попытка уйти от сиквела, чем реальная нужда в Монге. А вот реальная нужда появляется не так уж и часто.

Крута стаття. На яких об’ємах даних і активних з’єднаннях починає вигравати MongoDB? Дуже приблизно.

Особисто поки не лізу через відсутність стикання з біг дата і хай лоад. Якщо реляційна база добре працює — навіщо тулити NoSQL, вірно? Кількість полів і таблиць аргумент, але теж — від якої кількості схема бази стає роздутою? Мені подобається структурованість бази включно з типами — знаєш що є, плюс змушує думати як проектувати систему. А коли ти можеш вставляти рандомні ключі в будь-які записи, це спонукає не думати.

А ти хочеш її освоїти одразу на великому проекті? Замість того щоб підняти учбовий та подивитися як там шо?

Крута стаття.

Це вводна для самих-самих новачків. Навіть не лікбез. Там навіть не диявол в деталях, а цілий пантеон чортів та 100500 видів пекла на будь-який смак та гаманець.

На початку так і написано, що це оглядова стаття з історичним екскурсом. Якщо ви хочете деталі і практику, так є вже чимало книг по NoSQL.

Рекомендую книгу, очень неплохое овервью разных NoSQL баз и их сильных сторон:
www.amazon.com/...​rn-Movement/dp/1934356921

Чи можна запхнути всі дані в один документ? На жаль, але в MongoDB є обмеження на розмір одного документа — 16 Мб. Така межа цілком обгрунтована. Для прискорення роботи MongoDB намагається зберігати часто використовувані дані в пам’яті. А так як документ являє собою єдине ціле, то і завантажуватися він буде цілком і займати пам’ять.

Вот о чём точно не стоит жалеть, так это о максимальных 16 мегабайтах. На жаль, не указана критическая проблема, которая маячит на горизонте с таким подходом — locks. Запхнёте всё в один документ со многими уровнями вложенности, который будете часто менять — получите постоянное ожидание освобождения lock’а и резко просевший перформанс. При чём, в WiredTiger ещё более-менее, а раньше было ещё хуже.

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

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

Угу, давайте ещё специально писать что попало в коде, можно ж отрефакторить потом). NoSQL базы в большинстве случаев рассчитаны на «плоские» структуры и соответствующее использование данных. Поэтому иногда неплохо заходят для современных архитектурных подходов (CQRS, ES, микросервисы с небольшим количеством структур данных, которые позволяют обойтись без сиквельных референсов), а вот большинство проектов как требовали сиквел, так и будут. То есть, NoSQL сразу накладывает некоторые ограничения в зависимости от базы, и оптимизировать с пивом в руке не выйдет — здесь нет сиквельной универсальности и свободы. Не уверены, что выбирать, или рассчитываете на существенное изменение схемы, которая потребует референсов в будущем — выбирайте сиквел.

Я ничего не говорил про «давай в коде». Исключительно по NoSQL как способу хранения. И поскольку нынче мало что работает без бэкенда, напрямую коннектясь к базе, то как только ОДИН какой-то тип документ начинает создавать тормоза — то ТОЛЬКО ЕГО и стоит отрефакторить на бэкенде, поменяв его схему хранения, и мягенько провести подобное для следующих кандидатов.

Вот и всё. Остальное — пусть себе и дальше маячит. Я разумеется не агитирую создавать проблемы заранее, если сразу видно что в базе хранение идёт через жопу, то сразу и рефакторить, ещё до попадания в продакшен или в MVP стадии.

Лишь утверждаю, что львиная доля «маячащих» проблем таковыми не являются вообще, что имея бэкенд, достаточно легко решать проблемы хранения ПО МЕРЕ ПОСТУПЛЕНИЯ, не пытаясь творить предсказаний будущего на кофейной гуще. Цена решения медленно возникающих проблем сильно дешевле когда проблема уже известна и понятна (но ещё и близко не критична). Примерно в 100 раз выгода.

Исключительно по NoSQL как способу хранения. И поскольку нынче мало что работает без бэкенда, напрямую коннектясь к базе, то как только ОДИН какой-то тип документ начинает создавать тормоза — то ТОЛЬКО ЕГО и стоит отрефакторить на бэкенде, поменяв его схему хранения, и мягенько провести подобное для следующих кандидатов.

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

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

За выбор базы в целом никто не спорит. С SQL базами, внезапно, то же самое. А ну попробуй с семейства MySQL прыгнуть на Майкрософтовскую или Оракловскую, да там не один админ застрелится в процессе миграции

да там не один админ застрелится в процессе миграции

недавно доклад смотрел — платформу обслуживающую многих клиентов пытались с MySQL на Postgress перевести. Доклад можно назвать так:
Почему за несколько месяцев работы это невозможно.

не зберіг.
та й статей на різних мовах достатньо, про порівняння MySQL та Postgress щоб зрозуміти що просто не буде.
Нє, звісно що якщо як key-value storage — то різниці і не побачите.
хоч на SQLite переходьте — все ORM зробить

В Космосе такая же фигня: про partition key нужно думать сразу, т.к. получим full scan’ы с огромным количеством RU и соответственно ценой использования, а при большом количестве данных — отсутствие even distribution/проблему hot spots. Но в Кассандре да, самый хороший пример эдж-кейса — там и query’ить в обычном понимании-то нельзя, т.к. это по сути cache-like хранилище, просто с очень крутым линейным скейлом, который позволяет решить проблему огромных нагрузок.

Ну вцілому так. Не можна бездумно брати в проект Монгу якщо ти не розумієш для чого вона тобі там. А щодо еволюції схеми данних це цілком нормально, монгівці от прямо так і пишуть в своїх доках і курсах: «Схема документів повинна еволюціонувати разом із проектом. І повинна враховувати особливості Монги та те як данні будуть реквестатись і т д»

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

Ага, кодити не тільки відносно різних версій кодової бази, а ще й думати на яку версію схеми даних цей код працює

Бо пакетну зміну даних провести — це окремий ґеморой

Мрія

Вот о чём точно не стоит жалеть, так это о максимальных 16 мегабайтах.

Не стоит недооценивать криворукость разработчиков даже в таких крупных компаниях. Ограничение в 16мб херит саму идею докумеетоориентированных систем. Смысл документа, что он может быть большим, как страница Доу или страница в соцсетях. И вряд-ли стоит добавлять баннер при добавлении нового комментария «прасти братан мы упёрлись в 16мб».
Локи на уровне документа тоже фейспалм. Должни быть на уровне атрибута документа. Должни быть транзакции и джоины. Весь документ не должен грузится в память полностью, а только часто используемые секции. (Паретто не не слышали). Но ничего этого нет и только через 10 лет начинает доходить, что никаких идиодогических причин кроме кривых рук монгописцев которые со второго раза не угадали с движком — нет.
Вообщем тут можно было бы развести крупный технический холивор, но просто не хочется.

Ну, я бы послушал, почему так получается, что разные NoSQL базы обладают ограниченными возможностями по сравнению с сиквелом (каждая по-своему). Может, потому что технически это не так просто с учётом того, что эти базы — ещё и распределённые, и дело не в Монге конкретно?

Может, потому что технически это не так просто с учётом того, что эти базы — ещё
и распределённые

Внезапно, но в томже mssql есть distributed транзакции, хоть и со своими ограничениями.
Что мешало это сделать в Монго 5 лет назад. А нет, погодите, они введут это в новой версии движка через 5 лет, который успеют переписать с нуля по третьему кругу.

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

но CAP теорему никто не отменял,

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

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

Отказоустойчивости в таком случае тоже

вообще нет.

В очередной раз не вижу смысла мешать разные проблемы и пытаться найти какой-то субъективный микс. В таком случае можно взять Amazon Aurora и не париться с шардингом даже.

В очередной раз не вижу смысла мешать разные проблемы и пытаться найти какой-то субъективный микс. В таком случае можно взять Amazon Aurora и не париться с шардингом даже.

Можно взять. Но мы начали с того, почему в Монго нет транзаций, почему документ ограничен 16 мб, почему локи на уровне документов. И другие косяки.
И мой вердикт прост, потому что «несмогли», а не по какимто идиологическим причинам.
Идиологические причины то как раз наоборот. Область применения документоориентированных субд могла бы быть куда шире, чем есть на данный момент у монго. Если бы конечно написали изначально нормально.

Но мы начали с того, почему в Монго нет транзаций

потому что появились задачи где они — не нужны.

почему документ ограничен 16 мб

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

на примере «страницы ДОУ»:
вы можете представить статью или комментарий в 16 мб букв?

И мой вердикт прост, потому что «несмогли», а не по какимто идиологическим причинам.

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

Область применения документоориентированных субд могла бы быть куда шире

область примененения — и явилась причиной появления монг.
а NoSQL были задолго до их появления.

просто вы не в курсе.
но их не называли — NoSQL
потому что самой абревиатуры еще не существовало — SQL

и главная буква в нем:
Structured

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

потому что появились задачи где они — не нужны.

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

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

Откройте уже для себя наконец пейджинг в юай. Или тотже коллапс комментариев на доу.

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

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

как только вы куда угодно добавляете structured — вы обречены повторять путь что прошли реляционные БД.

Внезапно, но в новых версиях Монго появились зачатки на валидацию данных. Не прошло и 10 лет для того, чтобы понять, что если в документе будут валидаторы, хотябы на некоторых полях NoSQL не налетит на небесную ось и не превратится из тыквы в TSQL или PLSQL.

Откройте уже для себя наконец пейджинг в юай.

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

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

Я просто называю вещи своими именами.

у вещей нет своих имен.
это выяснено еще средневековыми схоластами.

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

Внезапно, но в новых версиях Монго появились зачатки на валидацию данных.

да вы что?

надо же, а я думал что это выдумки о документориентрированных БД:
Подобно иным документно-ориентированным СУБД .... и в отличие от реляционных СУБД, ... предназначена для работы с полуструктурированной информацией и имеет следующие особенности:

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

может потому что сам такие писал на БД родившейся и успешной в проде еще до первой работы Кодда?

И даже транзакции начали появлятся.

надо же какая круть, транзакции начали появляться!

Афигеть, вот это ноу — хау, так да. транзакции. революция в мире БД!

данные сохраняются не в строках и колонках, а в виде JSON-подобных документов, моделью которых является не таблицы, а деревья;

Вообщето не JSON а скорей BSON, если речь о Монго. Текстовый джисон никто не хранит. Хорошо что у монгописцев хоть с этим не возникло проблем, понять как должно быть. В случае Днипро, джисон хранится вообще как разрезанный список ключей в Trie структуре. От чего вес обновления/чтения одного атрибута документа, равен весу обновления/чтения в Key/Value хранилище. Тоесть это зачастую даже не микросекунды, а наносекунды на обновления джисон документа по любому из атрибутов.

В остальном я изначально не хотел начинать эту дискуссию, зная что она скатится в холивор. Есть люди, у которых устоялись взгляды. Ну показывали людям всю жизнь Жигули, откуда у них должно быть представление о том как ездит Ферари. Это ожидаемо. И моя цель (пока что) не грести сильно против течения. Но придет время и мы во всем обязательно разберемся, как должни быть устроены такие системы хранения данных =)

Вообщето не JSON а скорей BSON, если речь о Монго.

вообще-то байты и есть байты.

Текстовый джисон никто не хранит.

а что такое — текстовый и не текстовый на файловом уровне?

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

Поясните разницу, про «Текстовый джисон никто не хранит»?

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

и?

а где документ «страница ДОУ» у вас хранится?

Ну показывали людям всю жизнь Жигули, откуда у них должно быть представление о том как ездит Ферари

да, люди они такие. гении им светлое будущее обещают, а они все на жигулях норовят ездить :D

нет чтоб на ферари картошку возить, и для прохождения ТО закладывать квартиру. чтоб кредит взять в банке.

вообще-то байты и есть байты.

Не все байты одинаковы полезны. Особенно в кодировках ANSI и Unicode.

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

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

а где документ «страница ДОУ» у вас хранится?

В RAM как набор ключей в HArray.
С проектом Вы можете ознакомится здесь.
github.com/Bazist/HArray
Кстате это мой ответ на хештаблицы и красно черные деревья, которые тоже заняли незаслужено большую нишу.

Не все байты одинаковы полезны

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

Я могу только приклониться перед Вашим опытом.

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

я просто упомянул что там внутри — все байты.
а какую информацию содержат — то уже интерпретация.

и как всякая интерпретация — это не нечто данное Свыше.
а — условность.

И да, у меня есть свой уникальный взгляд на вещи.

то есть я правильно понял вашу идею?
про хранение комментов в «документе тема»?

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

мне в основном глубоко фиолетово что там под капотом у БД.

поэтому и ваши наработки — обратитесь куда-то в core team монги или марии.

С проектом Вы можете ознакомится здесь.

про «документ страница ДОУ» давайте
и документ «комментарии автора X»

да это понятно что кругом криворукие программисты, от NASA до команд монгодб, касандр и прочих каучдб.

И это действительно так. Технические работы для НАСА (включая средства доставки и то, что доставляется) — выполняют многочисленные подрядчики (частные компании, с хорошими спецами).
А всякие «оупен-соурс проекты» — как правило, годны лишь на применение в школьных/институтских лабораторках (и далеко не все проекты).

Должни быть на уровне атрибута документа. Должни быть транзакции и джоины.

и мы плавно переизобретем реляционные отношения :)
и вместо NoSQL получим NewSQL, ModernSQL, ..., TikTokSQL!

а смысл? они уже сейчас реализованы.

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

Welcome to IBM Lotus Notes

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

и мы плавно переизобретем реляционные отношения :)

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

атрибутов документа

это уже схема.
без схемы — залочили документ — и обновляйте себе «атрибуты» :)

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

Пример на пальцах.

я к тому, что хайп NoSQL уже прошел.
и как раз из-за того что он No

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

моя операция должна лочить всю страницу доу ?

по сути никакой страницы доу не существует :)

Просто поверьте, монгу можно было написать сильно лучше.

зачем мне веровать, незнамо кому? даже известному на доу?

я эти «страницы» делал многократно. и на html и как SPA
Никакой связи страниц, деревьев комментариев, и прочего и типа БД — не существует.
Тип БД никак не навязывает то что увидит пользователь, и с чем он будет работать.

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

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

сделать «сильно лучше» чем у зрелых РСУБД все равно не получится :)
а вот появления в них поддержки работы с json намекает что проще к ним добавить возможности NoSQL

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

Чтож в этом наивного, даже в такой несколько наивной поделке как документоориентированной СУБД Днипро, собранной за неск недель, были три вида транзакций (снапшот, Рид коммитед, репитбл Рид), гранулярные локи на уровне атрибутов и даже джоины. АСИД, а также каскадные транзакции (но тут уже наговнокодили в мсскл).

по сути никакой страницы доу не существует :)

Скорей в окружающем мире таблиц не существует. А документ, куда не плюнь попадешь в документ. И то что в реляционке страница Доу не будет выглядеть как документ, говорит лишь о том что придется немало наговнокодить всяких маперов даперов и прочего хлама чтобы документ конвертировать в таблицы а потом обратно. И самое печальное, что все эти джоины и селекты лягут на плечи проца чтобы увидеть то .... что собственно страница Доу изначально из себя представляла, тоесть документ.
И такая фигня не только с доу. А с 90% корпоративных приложений. Просто убогость монги не позволяет переходить на нее более серьезным приложениям, хотя разработчики понимают интуитивно мощь документов (но не тех конечно что 16 мб ограничили)

даже в такой несколько наивной поделке как документоориентированной СУБД Днипро

не слышал нигде о ней в проде, кроме как на доу.

Скорей в окружающем мире таблиц не существует

да, их тоже не существует.
но они более элементарная абстракция чем «документ»

а с более элементарных абстракций легче собирать более крупные, а не наоборот

А документ, куда не плюнь попадешь в документ.

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

И такая фигня не только с доу. А с 90% корпоративных приложений.

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

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

никакой страницы доу не существует.
это знает даже начинающий верстальщик HTML

не слышал нигде о ней в проде, кроме как на доу.

Потому что там есть другие проблемы, которые стоило бы пофиксить.
(Например перерасход по памяти и инмемори с журналированием, а стоило бы хранить на диске как LSM)

да, их тоже не существует.
но они более элементарная абстракция чем «документ»

а с более элементарных абстракций легче собирать более крупные, а не наоборот

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

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

Потому что там есть другие проблемы, которые стоило бы пофиксить.

та я и не сомневался что именно поэтому.

как ни вкусен изюм в булочке — ценность булочки в тесте, а не в изюме :)

а всякие «в ... реализована киллер-фича ...» - обычно как раз такой изюм. без булочки.

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

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

Страница Доу это страница Доу

это ваши галлюнации.
вам достаточно в браузере нажать (обычно) Ctrl-U чтобы развеять эту иллюзию.

но общая структура документа от этого не изменится

вам надо только разобраться в мелочи
где эта структура — у вас в голове или в коде :)

А если изменится, то и в РСУБД сплошь и рядом проекты по миграции данных от версии к версии.

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

Миграции же данных да, бывают.
И смены типа БД бывают.
Но совсем не потому что меняется то что видит пользователь.

Страшно далеки вы от народа, если не понимаете что скрыто в фразе:

Формат хранения данных прибит гвоздями к UI. Намертво.

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

А также то, что при росте нагрузки не придется городить амазон.

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

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

И на вашем проекте все почти ровно также. Если связи между сущностями в вашей РСУБД не изменились, то и документ скорей всего тоже не изменился. Доменная модель осталась одна и таже.

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

А также то, что при росте нагрузки не придется городить амазон.

а его не надо городить
даже на доу Solution Architect’ов полно.

Вы почемуто путаете. Документ, это не фронтенд.

Я?
у меня точно ник другой, чем у:

Пример на пальцах. Эта страница на доу по сути документ
Например все комментарии обьединены тем, что принадлежат одной теме.

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

Поэтому они в одном документе.

можно да, впендюрить их в один документ

а можно разбить на документы:
топик темы
связанные с темой комментарии.

огласите причины — считать комментарии неотъемлимой частью документа — «тема»?
а я хочу свои комментарии в разных темах посмотреть:

Если вам понадобится документ, где вы видите все свои комментарии — это другой документ

аха, то есть
при появлении комментария — помещаем его в документ тема
и в документ — «комментарий автора X»

А когда понадобится посмотреть комментарии по дате:
Создаем документ дата Y и помещаем комментарий еще и в этот документ.

А когда надо посмотреть документ — комментарии с более трех лайков
делаем документ «Комментарии с 3+ лайков»
для 4ех — «Комментарии с 4+ лайков»

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

я правильно понял идею?
или как всегда, туплю постыдно?

а данные пользователей — авторов и лайкнувших тоже там, в этих документах будем хранить?

И на вашем проекте все почти ровно также. Если связи между сущностями в вашей РСУБД не изменились, то и документ скорей всего тоже не изменился

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

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

аха, то есть
при появлении комментария — помещаем его в документ тема
и в документ — «комментарий автора X»

А когда понадобится посмотреть комментарии по дате:
Создаем документ дата Y и помещаем комментарий еще и в этот документ.

А когда надо посмотреть документ — комментарии с более трех лайков
делаем документ «Комментарии с 3+ лайков»
для 4ех — «Комментарии с 4+ лайков»

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

я правильно понял идею?
или как всегда, туплю постыдно?

а данные пользователей — авторов и лайкнувших тоже там, в этих документах будем хранить?

Частично только поняли идею. Поскольку даже Монго предоставляет аналитические запросы по документам.
Итого

делаем документ «Комментарии с 3+ лайков»
для 4ех — «Комментарии с 4+ лайков»

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

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

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

делаем документ «Комментарии с 3+ лайков»
для 4ех — «Комментарии с 4+ лайков»
Не понадобится.

почему не понадобится?

вы знаете что в будущем будут просить посетители доу?

Но некоторая избыточность по хранению информации всеже есть

хороша же некоторая, если комменты — основная часть контента доу :)

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

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

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

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

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

В этом смысле документоориентированные базы могут предоставлять заранее агрегированные данные

когда агрегаций пару штук. в «бложике». да.

я не считал сколько у нас. потому что — появляются новые и меняются старые.
да и никто их не считает. это нелепость какая-то.

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

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

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

но изобретателей велосипедов это конечно не остановит :)

Что сильно снижает нагрузку на систему.

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

почему не понадобится?
вы знаете что в будущем будут просить посетители доу?

Они сейчас не просят

делаем документ «Комментарии с 3+ лайков»
для 4ех — «Комментарии с 4+ лайков»

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

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

Я вроде как написал, что Монго криво написан. На самом деле гранулярность локов должна быть на уровне атрибутов документов (в рсубд сделали на уровне строк и это правильно).

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

Все верно. Индексы в Монго есть с первой версии. А в Днипро так вообще каждый атрибут проиндексирован по дефолту.

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

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

Они сейчас не просят

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

Нет предпосылок что попросят в будущем.

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

так что я очень сомневаюсь в ваших пророческих способностях.

Я вроде как написал, что Монго криво написан.

в код не смотрел. не могу сказать.

а вот ваша идея с «некоторой избыточным хранением данных» да, ничего личного
нубская :)

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

но вы уверены что это свежая, а главное — очень продуктивная идея.
ну ок.

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

ну куда мне такое учитывать.

Тоесть условно на примере страница доу будет прочитана в среднем в 100 раз чаще, чем отредактирована.

тут недавно один писал мне

Вы почемуто путаете. Документ, это не фронтенд.

обсудите с ним, пусть он вам пояснит что вы путаете.

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

не-а.
я как раз о чтении данных.
несколько избыточное хранение данных автоматически влечет и несколько избыточное их чтение.

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

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

А так как без кеширования — и вы не обойдетесь, то придется занимать бОльшее количество памяти — ведь «несколько избыточно» придется хранить эти лайки и там.

И само кеширование — в несколько уровней, давно решает проблему «заранее подготовленных агрегаций».

Итого, завершаю.

Я не знаю какие преимущества у Днипро перед Монгой
но ваш подход точно для мелких «бложиков».

страница доу будет прочитана в среднем в 100 раз чаще, чем отредактирована.

думаю число 100 сильно занижено.

но вам все же стоит подумать о том
что такое страница доу
и почему фразу:

Формат хранения данных прибит гвоздями к UI. Намертво.

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

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

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

Ну вот вверху есть интересный коммент
dev.to/cheetah100/comment/pj75

when Noah says «one of the most important parts of designing a system is fleshing out your data model».

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

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

я как раз о чтении данных.
несколько избыточное хранение данных автоматически влечет и несколько избыточное их чтение.

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

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

Формат хранения данных прибит гвоздями к UI. Намертво.

Не более чем данные в рсубд прибиты fk.
Еще раз повторюсь, документ это набор сильно связанных сущностей. То что на примере доу юай совпал с документом, ну так бывает в большинстве случаев. Это нормально. Деревья понимаете ли все дела.

ваш подход точно для мелких «бложиков».

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

Тоесть ваша рсубд с ее селектом больше коментов чегото там уже пролетает мимо :)

руки надо прямые — и не будет пролетать.

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

в рам достаточно попадания — горячих данных.

Не более чем данные в рсубд прибиты fk.

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

так что они там — не прибиты

движения головок винчестера и тп.

купите чуть дороже хостинг.

Это же азы. Чтение в документоориентированных системах будут В РАЗЫ лучше чем в рсубд,

рылли, в разы?
не, конечно подобрать такие кейсы можно. да плюс выкрутить все что можно в минуса у рсубд.
Это же азы фейк тестов :)

например — вырубить query cache у рсудб а у «nosql» оставить, потому что его вырубить нельзя.
и радоваться победе!

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

у бложиков.

а у финансово-экономического ПО — строго наоборот.
Даже когда есть понятие в руководстве пользователя — документ.

Что наиболее значение имеет так называемое сик таймс.

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

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

Заберите или вынесете эту ф-сть под капот СУБД и получите почти в любой интерпрайз системе круд с «бложиком»

глубокий спец в энтерпрайзе, да...

— ваш подход точно для мелких «бложиков».
— Это вы знать не можете.

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

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

но вы этого явно понять не можете. гений же «во всем» :)

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

Мы говорим о алгоритмах или мы в салоне продаж серверных стоек для вертикального масштабирования ?

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

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

а у финансово-экономического ПО — строго наоборот.

Здесь хотелось бы увидеть пример. Вот чтобы точно не легла на структуру «бложиков». Я в свою очередь, понимая хорошо структуры данных, могу сказать что не только на Документоориентированной, да на обычном Кей/Велью можно построить абсолютно любую прикладную модель данных.

а вот вывал всех в браузер пользователя — исключение.

Я для вас уже третий раз пишу, что используют projection, тоесть грузят например айтемы с массива документа с 10050 по 10060 если понадобится, а у вас все вываливают да вываливают в браузере. Печально.

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

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

И еще момент. Базы данных сейчас активно развиваются. Например за вчера я узнал что существуют FaunaDB и Yugabyte которые создали буквально 3-4 года назад. Которые существенно отличаются от классических решений. Не нужно думать что все кто придумывает базы данных «гении». Всеголишь люди которые видят проблемы в индустрии и могут предоставить их эффективное решение.

Мы говорим о алгоритмах

Вы говорите об алгоритмах. и пытаетесь говорить о другом :)

Азы матчасти по базам данных. Странно такое слышать.

вы мне еще букварь зачитайте :D

Здесь хотелось бы увидеть пример

октройте любой скриншот в гугл поиске ERP UI

Вот чтобы точно не легла на структуру «бложиков»

точно не ляжет.
каких только не перевидел и не писал сам.
еще на С писал, было дело, система продажи билетов.

но вы да, зачитайте мне букварь.

Я для вас уже третий раз пишу, что используют projection, тоесть грузят например айтемы с массива документа с 10050 по 10060 если понадобится, а у вас все вываливают да вываливают в браузере. Печально.

Вы писали о включении всего в один «некий документ»
Чтобы выбрать из него быстро байтики с 10050 по 10060 комментов — надо адресовать эти позиции
значит надо, как вы его не называйте — индекс.

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

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

да на обычном Кей/Велью можно построить абсолютно любую прикладную модель данных.

да.
и сайты можно писать на ассемблере

Вообщето в простонароде моя квалификация фулстак

ну, как понимаете, будучи в мире пхп последние 5 лет — мне очень хорошо известно кто такие фулстеки.

обманывает вас народ :)

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

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

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

в древности была классификация
системный программист
прикладной программист

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

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

октройте любой скриншот в гугл поиске ERP UI

ERP более чем прекрасно ложится на докуметалку. Это теже товары и процессы на производстве которые описываются документами. До компьютеров описывали в бумажном виде. Что тоже документы.

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

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

Ещё показательная ремарка.
Рсубд будет быстрее считать запросы Аля «а сколько пользователей оставило коментов в этом месяце». «Топ пять спамеров месяца».
А документалка именно прикладные запросы типа получить тему с комментами.

Так вот аналитику считают 3.5 калеки и могут при случае подождать.
А вот станет ли терпеть тормоза юзер, которых тут под 100 тыс, вопрос риторический

А документалка именно прикладные запросы типа получить тему с комментами.

Як це буде виглядати в темі з 5к коментарями?

А вот станет ли терпеть тормоза

Про які тормоза йде мова і чому їх не буде в noSQL?

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

Навіть як відмазка відповідь так собі
Як воно насправді буде виглядати, не в теорії?

А вот станет ли терпеть тормоза

Про які тормоза йде мова і чому їх не буде в noSQL?

А вот станет ли терпеть тормоза юзер, которых тут под 100 тыс

и сколько сайтов в мире имеют такую нагрузку?

какой статистике доверите, ее достаточно в инете, по первому миллиону топовых

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

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

и сколько сайтов в мире имеют такую нагрузку?

Я понял вашу квалификацию.
— У вас алгоритм уг
— Я поставлю мощнее сервер

Следующий.

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

Ну так дайте лінк, де ви пояснюєте магію

Тобто ви не знаєте як монга працює з диском і маєте дуже поверхневі знання про роботу рсубд

Очікувано

Ви це не показали в приведеному лінку
Тому — ні, не знаєте

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

Удачі

писать вы можете что угодно

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

и у NoSQL другие преимущества, ради которых его выбирают

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

Запрос страницы Доу это фейковый тест ?
ОооооК.

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

что же до доу
тема с 4603 коментов
gzip 1,14 МБ (реальный размер 6,42 МБ)
6,61 сек
догадываюсь что там все комменты отправляются,
код страницы пока не открылся.

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

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

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

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

аналогия — не аргумент

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

пока не вспомню что такая ситуация просто невозможна :)

расхожие страшилки, как у детей «страшные истории» мне можете не пересказывать.

примерчики давайте :)

когда они обеспечивают ту самую целостность :)

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

Вставка чаилда у которого парента не существует ?

как она возможна?
откуда он вообще может взяться?

но ок, появился этот забавный набор байт — какой ID его парента у него будет?
почему у «orm» а не установлена проверка при записи «exists»?

Надеюсь вы конечно же пишите дополинтельные скрипты чтобы чекать консистентность базы хотябы время от времени ?

пока не доводилось.
хотя там писать то
select left join и проверка на нулл
такое на собесах джунов спрашивают

Давайте УЖАС, а не этот смех джуновский

как она возможна?
откуда он вообще может взяться?

Вы мне напоминание огородника, который рвет бурьян голыми руками. К нему подходишь и говоришь, удобнее делать в перчатках или взять мотоблок. И ничего кроме как «да я этот бурьян голыми руками с семидесятых». Что за смех джуновский вырвать голыми руками этот борщевик. И так далее. Я тут подумал и понял. Работайте как привыкли. Без ФК значит без ФК.

вы не ответили на вопрос.
слив защитан.

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

пережовывания уходящих технологий.

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

а пакт о перемирии конечно принимается.

это времена мейнфреймов

Не спешите с выводами. Мы прошли путь от меинфреймов до персоналок и вернулись на клауды. Все может быть.

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

клауды никак не похожи на майнфреймы.
слитые вместе ui и бд
для обывателя одно и тоже.

Может для вас как для обывателя юай с бд кажется слитым (нет).

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

что с топором войны то?
сливайтесь уже окончательно, а то начали мне приписывать то за что я вас тролю :D

сливайтесь уже окончательно

Всё-таки недержание. Ну бывает.

«космических технологий» тут точно не нужно.
даже, вроде ж питон на беке, перенявший славу по тормознутости у руби не проблема в таких случаях.

Самые продвинутые системы комментариев, автоматически обновляются, добавляя новые комментарии, без обновления самой страницы по ф5.

Не подскажите, какие есть средства в рсубд, чтобы получить асинхронное обновление страницы ?

какие есть средства в рсубд, чтобы получить асинхронное обновление страницы ?

а зачем там эти средства, если это делается на фронтенде средствами js?
а в гуях — в отдельном потоке?

не, может и надо бы там такие.
понять только нужно — нафуя?

Самые продвинутые системы комментариев, автоматически обновляются, добавляя новые комментарии

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

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

решение задачки с литкода — и то вызовет бОльшее уважение.

а зачем там эти средства, если это делается на фронтенде средствами js?
а в гуях — в отдельном потоке?

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

Я спросил, что рсубд может предложить для асинхронного программирования и асинхронной работы интерфейсов

отвечаю нубу

Есть две основные специализации у программистов — бекенд и фронтенд.
Бекендеры не знают, в общем случае — НИЧЕГО об интерефейсе
Фронтендеры не знают, в общем случае — НИЧЕГО о бекенде
За — ненадобностью, а не потому что невежественны

И есть программисты фулстеки. Которые быстро переключаются
То он бекендер — который ниего не знает об интерфейсе
То он фронтендер

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

Исключение — классический php — где веб фронтенд в виде html генерируется на бекенде. Но и там — основная технология асинхронного UI — pjax — не требует никаких «асинхронных средств» у любой БД

Другими словами, что будет с рсубд если каждая открытая страница на доу будет каждую пару секунд спрашивать «а есть ли новые сообщения на доу»

пушной зверек ей будет.
Поэтому стопицот эонов назад такой метод, названный short polling — объявлен как метод глубоких инвалидов.

На самом деле, бывает применяется, когда надо бытенько накостылить :) и тоже можно обойтись без сервера БД, и тот же чат сделать — чисто на файликах на сервере.

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

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

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

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

я ответил — как решается эта задача.

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

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

только алгоритм — это крохотная часть программы.

а как делать программы — вы не в курсе.
и несете ахинею :)

только алгоритм — это крохотная часть программы.

Мы в топике про монго.
Монго это крохотная часть программы ?

а как делать программы — вы не в курсе.

Ну хоть на FK не экономлю.
И вам советую убрать говнокод и вернуть ключи на место.

Монго это крохотная часть программы ?

за годы хайпа я достаточно пересмотрел и материалов по монге, и тестов где она «в разы» обскакивает.

и преимущества монги понятны.

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

Ну хоть на FK не экономлю.

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

И вам советую убрать говнокод и вернуть ключи на место.

два сторонних техаудита пройдено.
чтобы советы гениев с доу слушать.

как и до этого применял подобные вещи — бизнес доволен и программисты тоже никакого говнокода не увидели

а вы да, дальше зазубривания букваря не дошли, а в букваре ж Абсолютные Истины, да :)

ERP более чем прекрасно ложится на докуметалку

гы :)

Это теже товары и процессы на производстве которые описываются документами.

счеты или потом калькулятор у бухгалеторов на столах не замечали?

Мне кажется вы всё ещё не понимаете как работают рсубд.

да мне давно понятно что вам же кажется :D

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

все нормально.

С индексами или без документалка даст прирост в раз сто, может и более.

угу. в вашем идеальном мире :)

в реальном не дает.

И кеш рсубд сильно не спасет ситуацию.

ну, у вас не спасает
у нас, простых смертных результат тяжелых запросов с секунд, в первый раз, БД потом отдает в районе 5-7мс

но вы рассказывайте, рассказывайте.
гения всегда полезно послушать :)

счеты или потом калькулятор у бухгалеторов на столах не замечали?

Бизнесс логику в документалке никто не отменял. Она в трехзвенке стоит посередине.

у нас, простых смертных результат тяжелых запросов с секунд, в первый раз, БД потом отдает в районе 5-7мс

Мне хватает ваших откровений что в вашей говнобазе забыли FK добавлять.

Дальше не продолжайте.

Мне хватает ваших откровений что в вашей говнобазе забыли FK добавлять.

не забыл, а преднамерено :)
сознательно.

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

Дальше не продолжайте.

прикольный вы нуб все таки :)

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

Так принимайте осознанные проектные решения, а не бегите при первом чихе за сервером помощнее, как только вас тыкнули в незнание матчасти.
И это, люди нашей специальности должни учится всю жизнь, даже в 60 лет. Я сам фанат рсубд и сертификаты имеются ещё на версию мсскл 2000, но тем не менее рассказываю на пальцах и показываю, как можно написать систему лучше.

Так принимайте осознанные проектные решения

вы с байтами на диске разберитесь, и с горячими данными

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

не люблю продавливать весом решения.
это обычно вредно для проекта.

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

а не бегите при первом чихе за сервером помощнее

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

И это, люди нашей специальности должни учится всю жизнь, даже в 60 лет.

ну, вы протелепатировали что я не учусь. ну ок.

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

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

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

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

вы с байтами на диске разберитесь, и с горячими данными

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

не люблю продавливать весом решения.
это обычно вредно для проекта.

Наверно поэтому вы сообщили о своем опыте, о менджерских буднях, о фокспро, о си и вот это вот все «да я в 70х ....» в рамках этого короткого топика.

как их можно правильно готовить.

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

Но уж поверьте, там тоже окажется много нового для вас.

когда же наконец начнете сообщать новое?

пока вы просто пережевываете материалы презентаций евангелистов NoSQL

а новое когда будет? оно у вас есть вообще, или надо оплатить выдачу этих тайных заклинаний?

Наверно поэтому вы сообщили о своем опыте, о менджерских буднях

вам — чтобы вы мне не пересказывали букварные истины :)

но вас толи заклинило, толи ничего нет, кроме этих букварных истин.

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

не советую кстати.
напартачат в большинстве случаев.

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

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

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

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

когда же наконец начнете сообщать новое?

Скоро, наберитесь терпения.

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

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

Скоро.

ок, подожду :)

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

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

а у вас бложики тормозят?
ну, для презренного вордпресса и я как-то за пару часов, и потом доводки еще с парочку, написал кешер, известные мне не нравились слишком развесистыми средствами для home user пользователей.

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

А как обеспечивать целостность данных при локе на уровне отдельного аттрибута?
Тогда выходит каждый аттрибут должен иметь версию и айди.
Если же обновление аттрибута будет увеличивать версию документа, то что делать с racing condition без лока документа?

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

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

так вот я о том же и подумал, что если каждый аттрибут становится рекордом, то чем это отличается от рсубд?

Если же обновление аттрибута будет увеличивать версию документа, то что делать с racing condition без лока документа?

Мержить, как вариант.

не очень понимаю как ты это видишь?
лочить версию документа?

Основною перевагою структурованих баз даних довгий час залишалася швидкість. Саме завдяки структурі. А ще — СТАБІЛЬНІСТЬ. Навіть якщо посипався носій даних (а це стається частіше ніж розповідають маркетолухи Сігейта), структурованим даним досить легко знайти відповідність та у короткий час повернути базу даних до ладу.

З неструктурованими даними зробити те саме можна лише додавши до них додаткові дані, що допоможуть зібрати уламки. Особисто я ніколи не піднімав розвалену Mongo, мої знання з того приводу можливо на кілька років застарілі, цікаво було б почути, як складається ситуація зараз.

Говорячи про збереження даних, ніколи не варто забувати про альма матер всіх баз даних: файлову систему. Вона також є базою даних по суті. І за більш як півсторіччя еволюції має прекрасну підтримку у всіх операційних системах, легкі та зрозумілі протоколи передачі, відносну легкість резервування, блокування на рівні операційних систем, а вишенькою на тортик — права доступу.

Левова доля даних має низьку цінність, невеликі вимоги до швидкості доступу, але саме вони своїм колосальним об’ємом роблять бази даних неповороткими. Викинувши все що не потрібно для оперативного пошуку у файли, можна зекономити ≈99% ресурсу бази. А ще — позбавити кеш від мотлоху.

Кешування файлів — то взагалі казочка з гарними кінцями. Це використання тимчасово вільної пам′яті під файловий кеш. Це відокремлення збереження на оптимальний з точки зору носій. Це використання серверів минулих поколінь для «чорної» роботи з файлами. А ще їх можна розкидати по всьому світу, назвавши це CDN.

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

Якщо коротко, то навчаючи зберігати дані, перш за все треба вчити саме ФАЙЛИ. А вже потім бази даних. Це лише міф, що проекти треба творити нашвидкоруч, а далі вони еволюціонують самі. В реальності вони тупо помирають, через те що структурна еволюція сховищ майже ніколи не закладена в бюджет. З файловим зберіганням більшості мотлоху це дасть фору рік-два, дозволяючи пройти цю кризу без гострих ускладень, а майже в зоні комфорту.

На файлову бд навряд чи варто довіряти щось цінне. А от, той же шардінг, йде на ура

А базу даних ти прямо на RAW PARTITION будеш ставити? Деякі бази таке вміють. Чи вміє монга — не знаю, не пробував.

PS. Ти вже довірив файловій системі всі свої персональні дані. Навіть фотки власних діток.

Є ж RAID і структури поверх ФС на різних інстансах, що контролюють цілісність даних на ФС

А вот не факт.
Из недавнего.
mysql после рестарта стал считать, что у него в логе последняя запись — неделю назад и похерил ВСЕ данные старше этого периода. После чего начал писать новые данные начиная с этого ИД, писал сутки.
Не, ну, наверно, можно их вытащить из innodb файликов, вот только проблема в том, что файлы десятки и сотни гигабайт и времени на понимания как это сделать — нету в бюджете.
В результате просто откатилися на последний бекап, благо есть бекапы каждый день. Но в связи с тем, что поздно заметили — два дня данных потеряли.о
И нет, проблема не в дисках,стоит на рейд контроллере с четностью.
prntscr.com/12hr8qw (заметьте разницу в ID, походу он на месяц минимум откатился).

Некисло так. А почему случилось не пробовали потом узнать?

Я конечно тоже параноик, и бэкаплю состояние денег и прочих активов примерно раз в 2-3 часа, но пока ни разу не понадобился бэкап. Закон подлости прям.

Рискну предположить повреждение данных прямо в оперативе. Либо это какой-нить «неважный» баг, исправление которого «забыли» перенести в предыдущие версии. Или не забыли, и базе данных всё же нужно проверить наличие апедйтов именно для своей версии.

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

Ну гугл ничего полезного не расказал. Читать код mysql для того чтоб понять мне влом, тем более что работа не будет оплачена и некритична(ну потеряли записей может еще на пару часов моей работы).
Порекомендовал клиенту пообщатся с mysql експертом если хочет востановить, скопировал ему отдельно папку /var/lib/mysql/
подозреваю смену версий, онлайн был около полугода.
Раз в два часа очень дорого обходится на любой разумной системе. Прежде всего по блокировкам и нагрузке.
Ну развечто у вас там доходы больше 3к в день. Одного дня достаточно. Я даже с реплик чаще не копирую. Просто держу реплики на проектах где больше 300 в день оборот и не перегружаю одновременно никогда.

суровая невезуха. я о такой не слышал.
все бывает, и даже то что не бывает :(

найбільш цікавий рецепт на тему відновлення після цієї помилки я бачив тут:
forum.hostmachine.net/viewtopic.php?p=715
Але це для панів, які мають час і натхнення, або не мають іншого вибору, тобто бекапу)

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

А для тих щасливчиків (буржуїв), які заплатили за підтримку, є Doc ID 1416063.1 на support.oracle.com
Там багато різних опцій насправді по лікуванню.

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