Comments 39
Я понимаю, что на каждом «взрослом» HL++ минимум пара докладов об этом, но всё же.
Всё новое, это хорошо забытое старое. Как вы думаете, какие БД использовались до появления SQL в 70х? Да, оказывается и тогда люди использовали БД — сетевые и иерархические, причем эти подходы продолжают использоваться по сей день, только теперь их стали относить к NoSQL :)
Черт! Пошел выпиливать монгу. А так все радужно начаналось.
Лучший из прочитанных мной обзоров зачем это надо + где и почему это не надо. Спасибище.
специальный механизм для хранения больших файлов, которые бьет файлы по 16 Мб и хранит эти части.Бъет файлы по 255kB (по умолчанию).
Как не надо использовать NoSQL базы данных? Не надо в них хранить реляционные данные.Очень популярный, но не правильный вывод (не точный), не нужно смотреть nosql это или реляционная БД. Нужно смотреть на фичи (и их отсутствие), сейчас реляционные базы втаскивают фичи из nosql и наоборот.
Например надо вам для проекта транзакции + джойны + безсхемность, — смотрите какие есть доступные варианты.
В некоторых NoSQL базах прекрасно строятся реляции, есть джойны и т.п. например тот же OrientDB, в нем, кстати, есть прямые ссылки, чего нет в реляционных БД, а это, возможно, самое то, что нужно для построения реляций. И это становится очевидно если представить как бы вы хрынили данные в переменных при программировании (могу привести пример).
он вложен в сериалы на 5 уровней вниз — достать его никакой возможности нет.Непотяно почему, но почти все БД «прибивают гвоздями» индексы к данным, хотя индексы — это совершенно оторванная сущность. (Для автоматической переиндексации?) Было бы не плохо чтобы была возможность произвольно задавать индексы для данных, тогда для примера выше, можно было бы «привязать» актеров к сезонам без изменения схемы (хотя там появтяются другие нюансы), а то что они жалуются на то что нужно дополнительно вытаскивать актеров — в MongoDB есть lookup (хотя появился не так давно), могли взять nosql где есть джойны, например OriendDB/ArangoDB, либо хранить актеров в кеше.
Можно переколбасить структуру данных и поднять актера на верхний уровень, а в объекте сезона хранить ссылки, но тогда мы теряем все прелести документной базы данных
Ешё камень в сторону MongoDB, она вроде как создана для больших данных, но с другой стороны она нещадно тратит хранилище, в итоге хранить большой объем не эффективно, наверно это «лозунг» для тех, кто считает что петабайты стоят копейки.
Эта на первый взгляд серебрянная пуля полна таких подвохов, что ручные джойны на клиенте покажутся сказкой.
>Было бы не плохо чтобы была возможность произвольно задавать индексы для данных,
Так они прекрасно и задаются так, как Вам надо в Монге. Или что-то другое имеется ввиду?
> нужно дополнительно вытаскивать актеров — в 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/
https://dbmsmusings.blogspot.ru/2010/03/distinguishing-two-major-types-of_29.html — тут можно прочесть больше про разницу и путаницу в терминах.
Самый распространенный вариант это наверное «вставка» nosql базы перед реляционной, в качестве буфера/кеширования. Банальный key-value redis с кешем данных на несколько секунд (зависит от задачи конечно) невероятно-чудесным образом разгружает SQL базу.
В Вашем примере про сериалы и фильмографию актера — как разработчики решили эту проблему? Перешли на SQL?
Почему вы никогда не должны использовать MongoDB
Я думаю, что правильное решение — в связке NoSQL СУБД + ElasticSearch.
Первый хорошо хранит и извлекает данные по ключам, а второй легко находит денормализованные данные по произвольному запросу.
ES не является СУБД. СУБД, помимо операций чтения, записи и поиска данных, должна обеспечивать хранение данных. Т.е. иметь качественый тулинг для:
- бэкапа и восстановления данных. Уточню, надежного и работающего бэкапа а не "скопируйте файлы базы"
- восстановления базы после программного или аппаратного сбоя. Совсем хорошо, если автоматического восстановления.
- просмотра и ручной модификации данных. Например, для "вычистки" грязных данных из базы
- ETL/другие формы импорта/экспорта.
Упрощая, должна быть процедура бэкапа, база не должна отказываться стартовать из-за отключения света, смены конфигурации кластера или неправильной фазы луны, база не должна лечиться перезапуском рабочих процессов, должен быть приличный GUI и SDK для разработчика, должны быть средства интеграции.
В большинстве NoSQL решений вышеописанное находится в зачаточном состоянии. Даже в той же монге.
Если вы получили это сообщение электронной почты по ошибке, просто удалите его. Вы не будете подписаны на нашу рассылку, если вы не щелкните по ссылке для подтверждения выше. И следующим письмом вам начнут приходить 18 лекций лучших специалистов Рунета по высоконагруженным системам.То есть если мне не нужна рассылка, я не хочу кликать на ссылку и мне просто нужен доступ к материалам — вам все равно по*уй и вы будете мне присылать письма?
highload.guide — это учебник, который приходит в виде отдельных писем по электронной почте. Вы не сможете получить к нему доступ иначе, чем подписавшись на него.
Да, мы считаем такой формат правильным и удобным — письма приходят в продуманном нами порядке, между письмами — пара-тройка дней на чтение и обдумывание.
Иногда мы шлём в рассылку, кстати (О Боже мой! :) рекламные письма про разные продукты, если считаем, что такие продукты полезны нашим «виртуальным студентам».
Как-то так.
Я ничего не понялЭто вот я не понял, поэтому и написал комментарий выше :)
письма приходят в продуманном нами порядке, между письмами — пара-тройка дней на чтение и обдумываниеВот так и надо было написать в письме: «материалы (или ссылка на них) будем присылать в письмах. В довесок можете подписаться на нашу рассылку, жмакнув на красную кнопку». Никаких вопросов, никакой двусмысленности.
Метод хранения никак не связан с реляционностью. Сейчас почти все РСУБД могут хранить данные построчно.
А разве HBase не key-value?
Яркий представитель этого класса — это Memcashed
Опечаточку бы поправить.
NoSQL – коротко о главном