Pull to refresh

Comments 39

Классные у вас статьи! Всё просто и понятно. Спасибо!
NoSQL на устах — нереляционная в уме. :)
Большое спасибо за обзор. Жаль не могу плюсануть — поэтому от себя — спасибо!
Спасибо! В программировании всё хорошо, что с умом, без фанатизма и рекламы. NoSQL — не панацея. Так же, как и SQL — не идеал.
Интересно, почему при такой широте обзора не было сказано ничего про Tarantool?
Я понимаю, что на каждом «взрослом» HL++ минимум пара докладов об этом, но всё же.
так разве кто заставляет? Можно же просто рациональные зерна написать, равно как и слабые стороны указать (если найдутся)
История баз данных у вас жидковата :)
Всё новое, это хорошо забытое старое. Как вы думаете, какие БД использовались до появления SQL в 70х? Да, оказывается и тогда люди использовали БД — сетевые и иерархические, причем эти подходы продолжают использоваться по сей день, только теперь их стали относить к NoSQL :)
Согласен с вами.
А еще раньше были реляционные NoSQL БД.
Например dBase.
Кстати насчет «Документ-ориентированных баз данных» почти все актуальные СУРБД это могут.
Как минимум хранение JSON/XML и поиск по ним
UFO just landed and posted this here

Черт! Пошел выпиливать монгу. А так все радужно начаналось.

Лучший из прочитанных мной обзоров зачем это надо + где и почему это не надо. Спасибище.

Использую NoSQL и MongoDB (совместно с реляционнми БД) 6+ лет, до этого просто реляционные, и вот какие у меня мысли:

специальный механизм для хранения больших файлов, которые бьет файлы по 16 Мб и хранит эти части.
Бъет файлы по 255kB (по умолчанию).

Как не надо использовать NoSQL базы данных? Не надо в них хранить реляционные данные.
Очень популярный, но не правильный вывод (не точный), не нужно смотреть nosql это или реляционная БД. Нужно смотреть на фичи (и их отсутствие), сейчас реляционные базы втаскивают фичи из nosql и наоборот.

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

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

он вложен в сериалы на 5 уровней вниз — достать его никакой возможности нет.
Можно переколбасить структуру данных и поднять актера на верхний уровень, а в объекте сезона хранить ссылки, но тогда мы теряем все прелести документной базы данных
Непотяно почему, но почти все БД «прибивают гвоздями» индексы к данным, хотя индексы — это совершенно оторванная сущность. (Для автоматической переиндексации?) Было бы не плохо чтобы была возможность произвольно задавать индексы для данных, тогда для примера выше, можно было бы «привязать» актеров к сезонам без изменения схемы (хотя там появтяются другие нюансы), а то что они жалуются на то что нужно дополнительно вытаскивать актеров — в MongoDB есть lookup (хотя появился не так давно), могли взять nosql где есть джойны, например OriendDB/ArangoDB, либо хранить актеров в кеше.

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

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

>Было бы не плохо чтобы была возможность произвольно задавать индексы для данных,

Так они прекрасно и задаются так, как Вам надо в Монге. Или что-то другое имеется ввиду?

> нужно дополнительно вытаскивать актеров — в MongoDB есть lookup (хотя появился не так давно)

Да ладно, ему сто лет в обед. И нормальным решением это не считается.

> могли взять nosql где есть джойны, например OriendDB/ArangoDB, либо хранить актеров в кеше.

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

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

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

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

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

Очень хочется посмотреть на пример. :)

как бы вы хранили данные в переменных при программировании

Например есть 2 коллекции/таблицы users и companies, нужно сделать связь user->company, как бы это было в sql базах (на javascript):

// Делаем связь
user.companyId = 42;

// Достанем имя компании
_.findWhere(companies, { id:user.companyId }).name;

Как бы это было-бы при использовании ссылок:

// Делаем связь, company - объект из другой коллекции/таблицы
user.company = company;

// Достанем имя компании
user.company.name;

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

Дошло! OrientDB выглядит очень привлекательно. Намучился с MongoDB. Собирался переехать на PostgreSQL — нужны связи. Но смущают тесты производительности https://www.arangodb.com/performance/


Предполагаю, что выборки по графам OrientDB будут быстрее цепочки джоинов в PostgreSQL, если рассматривать этот пример: https://habrahabr.ru/post/324012/

То что написано в разделе про column store, в общем случае, не относится ни к cassandra, ни к hbase. Не стоит путать column-family и column-oriented.
https://dbmsmusings.blogspot.ru/2010/03/distinguishing-two-major-types-of_29.html — тут можно прочесть больше про разницу и путаницу в терминах.
Спасибо за такой обширный доклад! Всё интересно. Присоединяюсь к коменту выше — спасибо от меня и «плюс» поставить пока возможности нет(
UFO just landed and posted this here
Целью этого доклада не было рассказать про хранение данных вообще или хранение данных в облачных хранилищах.

Ну и этот доклад прозвучал в 2015 году.
Ну и этот доклад прозвучал в 2015 году.
Это заметно по фразе:
пару месяцев назад, в марте, этих ребят купила компания Apple
Не очень понятно получилось. В Вашем примере про сериалы и фильмографию актера — как разработчики решили эту проблему? Перешли на SQL? Значит ли это, что NoSQL имеет смысл использовать только в проектах, в которых гарантированно не будет новых требований в будущем?
NoSQL есть смысл использовать тогда, когда это нужно и подходит вашему проекту, а не когда это модно и менеджЫр говорит что и нам надо.
Самый распространенный вариант это наверное «вставка» nosql базы перед реляционной, в качестве буфера/кеширования. Банальный key-value redis с кешем данных на несколько секунд (зависит от задачи конечно) невероятно-чудесным образом разгружает SQL базу.

Как правило, все бывает ровно наоборот с менеджерами. Я знаю PostgresSQL — будем использовать его. Менеджеры боятся всего нового, оно и понятно — это риски. А тащить что-то новое и вестись на хайп — это как раз для программистов-хипстеров. Зрелый подход, к счастью, тоже не редкость.

ES и есть NoSQL СУБД

Я думаю, что правильное решение — в связке NoSQL СУБД + ElasticSearch.
Первый хорошо хранит и извлекает данные по ключам, а второй легко находит денормализованные данные по произвольному запросу.

https://habrahabr.ru/company/oleg-bunin/blog/319052/#comment_10000052 — мобприложение глючит сильно при комментировании :(

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


  • бэкапа и восстановления данных. Уточню, надежного и работающего бэкапа а не "скопируйте файлы базы"
  • восстановления базы после программного или аппаратного сбоя. Совсем хорошо, если автоматического восстановления.
  • просмотра и ручной модификации данных. Например, для "вычистки" грязных данных из базы
  • ETL/другие формы импорта/экспорта.

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


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

Вы рассказываете о современных требованиях к промышленным СУБД, используемых для хранения важных данных. Но вряд ли я ошибусь, если предположу, что большинство эксплуатируемых сейчас экземпляров СУБД соответствуют этим требованиям и(или) эти возможности используются. Вы знаете, сколько в вашем телефоне СУБД? А данные скольких из них хоть как-нибудь копируются?
Интересная статья. Одним из плюсов NoSQL баз данных, на мой взгляд, является крайне быстрый старт которого вполне достаточно для использования основных возможностей буквально с первых минут после «распаковки из коробки».
Статья как краткий «справочник» хороша, захотелось узнать подробнее и я пошел по ссылке (HighLoad.Guide) из статьи. То, что стоит 17000 Р сейчас в открытом доступе! Круто, подумал я и без сомнений ввел свой e-mail. И тут… (выделение в цитате мое):
Если вы получили это сообщение электронной почты по ошибке, просто удалите его. Вы не будете подписаны на нашу рассылку, если вы не щелкните по ссылке для подтверждения выше. И следующим письмом вам начнут приходить 18 лекций лучших специалистов Рунета по высоконагруженным системам.
То есть если мне не нужна рассылка, я не хочу кликать на ссылку и мне просто нужен доступ к материалам — вам все равно по*уй и вы будете мне присылать письма?
Я ничего не понял.

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

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

Иногда мы шлём в рассылку, кстати (О Боже мой! :) рекламные письма про разные продукты, если считаем, что такие продукты полезны нашим «виртуальным студентам».

Как-то так.
Я ничего не понял
Это вот я не понял, поэтому и написал комментарий выше :)
письма приходят в продуманном нами порядке, между письмами — пара-тройка дней на чтение и обдумывание
Вот так и надо было написать в письме: «материалы (или ссылка на них) будем присылать в письмах. В довесок можете подписаться на нашу рассылку, жмакнув на красную кнопку». Никаких вопросов, никакой двусмысленности.
Если вы используете или собираетесь использовать распределенные NoSQL базы данных — срочно читать https://aphyr.com/tags/Jepsen. Кайл Кинсберри устраивает инквизицию разным базам симулируя разные состояния сети и нагрузки и смотрит соответствуют ли они маркетинговым обещаниям.
>Они немного по-другому хранят данные, нежели, например, реляционные базы данных — реляционки хранят по >строкам, т.е. все атрибуты одной строки лежат рядом. Эти делают наоборот, они хранят отдельно колонки.
Метод хранения никак не связан с реляционностью. Сейчас почти все РСУБД могут хранить данные построчно.

А разве HBase не key-value?
Спасибо, всеобъемлюще.

Яркий представитель этого класса — это Memcashed

Опечаточку бы поправить.
Only those users with full accounts are able to leave comments. Log in, please.