Comments 39
"документно-ориентированные СУБД" это видимо от слова документны ?
memcached сложно назвать базой данных, это скорее система кеширования. А для redis есть термин - это представитель no-sql баз данных.
Еще вы забыли о явно выделяющихся в отдельный класс TSDB
И я бы не назвал MongoDB документо-ориентированной. Это объектно-ориентированная база данных.
И я бы не назвал MongoDB документо-ориентированной.
"MongoDB is a source-available cross-platform document-oriented database program" из вики
В туториале они тоже называют себя именно документо-ориентированной базой
Вот только в том же туториале они парой слов позже поясняют, что они имеют ввиду под словом документ:
MongoDB documents are similar to JSON objects
Documents (i.e. objects) correspond to native data types in many programming languages.
В английском языке, слово document в общем значении имеет конечно текстовый документ с информацией или инструкцией, зачастую даже бумажный.
Но применительно к компьютерной терминологии, больше имеет значение как файл со своей структурой и информацией, то есть по сути - объект. И при переводе эта специализация теряется.
Отличная статья для новичков! Спасибо.
Яркие представители колоночных СУБД - .... Google BigTable,
Думаю вы перепутали с Google BigQuery.
BigTable совсем другая технология, ближе к ключ-значение. Хотя и элементы хранения по колонкам там есть, но в этом списке ей точно не место.
Спасибо за замечание.
BigQuery конечно будет релевантнее, ведь в BigQuery можно делать запросы из BigTable.
https://cloud.google.com/bigquery/external-data-bigtable#java
Я предлагаю так глубоко не рыть :). Потому что из BigQuery можно так же делать запросы и к MySQL и к PostgreSQL (если они в GCP развернуты через Cloud SQL). А к тому же Bigtable можно делать запросы не только из BigQuery, но и из PostgreSQL (есть расширение https://github.com/durch/google-bigtable-postgres-fdw). И так далее - многие базы данных умеют выставить через свой интерфейс чужие базы данных. Но это все побочные сценарии, часто идущие вразрез с основным режимом использования - просто для удобства, немного данных можно достать из внешней базы, чаще всего несколько баз нужно как раз потому что внешняя база совсем другая и данные в ней нужны для совсем другого.
Все переписать :) Шутка.
Сначала надо определиться, по какому признаку верхний уровень классификации. "Реляционные" описывает высокоуровневый интерфейс, а "колоночная" описывает физическое устройство базы, вместе их использовать не надо (бывают, скажем, реляционные колоночные). На самом деле похоже базы классифицируются не по первому, и не по второму признаку, а по типу использования. Группу "реляционные" я бы назвал "транзакционные" - рассчитанные на частые транзакции, и да, чаще всего нынче у них реляционный интерфейс, но не всегда. "Колоночные" по типу использования следует назвать "аналитические", и да, нынче в них модно использовать колоночное хранение данных, но бывают и кубы и прочее.
И конечно не забыть про прочие специализированные базы, вроде time series. Они наверное используются на практике не реже графовых.
Google BigTable и Cassandra (а также HBase, Amazon DynamoDB и некоторые другие) - это не колоночные базы. Это wide row базы - в одной строке может быть огромное число колонок, причём их имена от колонки к колонке могут не повторятья.
По сути же, это (Key,Key)->Value хранилища. Чуть точнее, (RowKey, ColumnName)->Value.
Отличительная особенность колоночных баз: чтобы отфильтровать по произвольной колонке, с диска нужно прочитать и распарсить только эту колонку, записанную весьма компактно. В Cassandra для этого нужно прочитать и распарить всю базу - что сразу ставит крест на применимости термина "колоночная" к Кассандре.
Картинка ужас.
В Customer зашиты Заказ и Инвойс
В Product - цена и количество.
Перекрестные ссылки друг на друга.
Как сломать понимающего и запутать новичка.
Встраиваемую SQLite можно было бы еще упомянуть наверное в реляционных.
а Teradata как то вы в стороне оставили
По классификации не согласен принципиально с многими утверждениями.
Когда выбирать реоляционную базу — практически всегда если не нужно обрабатывать
1) очень большой поток запросов
2) хранить очень много данных
Реляционные базы универсальны. Сейчас они могут хранить и неструкрутрированне данные в JSON или text/bonary полях. Все это хорошо пока данных становится очень много или запросов становится очень много и нужно масштабирваться. Реляционные это не умеют ока во всяком случае. Подмена на стороне сервера совместимыми с протоколом MySQL/Postgrеs клинетов распределенные азы данных конечно появились. Но имеют два недостатка: они на порядок медленнее чем сразу делают свое использование неэффективным, когда мы заменяем 1 сервер реляционной базы 10 серверами yogobyte и других эрзац-реляционных баз и получаем все еще ту же самую эжффективность запросов. Второе они пока еще очень нестабильны.
Поэтому приходится идти на компромисы и там где все признаки необзодимости испольщовать релационные базы данных — кроме только того что нужно иметь возможность горизщонтального масшабирования — использовать как раз NoSQL базы данных только лишь потому что их можно шардировать.
Мой список
Из обычных бд postgres потом mysql(Mysql не неумеет подчищать за собой раздутые таблицы)
Монго слишком дорого в обсуживание, данных под 2 тб.. 5 серверов, потихоньку делаю замену в пользу pg
Колоночные - кликхаус оправдал с старта
Из обычных бд postgres потом mysql(Mysql не неумеет подчищать за собой раздутые таблицы)
Умел и умеет. Насколько я понял имеется в виду таблицы innodb. Действительно если выбрано хранение одним файлом то пространство один раз выделенное не сокращается. Если хранение одна таблица=один файл — пространство сокращается. В последнрих версиях MySQL такой способ хранения задается по умолчанию. А раньше был одним файлом.
Как раз у Postgres больше проблем с раздутыми таблицами так как каждое изменения данных это фактичепски новая строка (хоня к старому варианту в явном виде доступа нет) vacuum не зря там есть такая команда
Полезная статья.
я вот не нашел ответов на свои вопросы:
1) использовал mongodb для отношения лайков для видео: VideoID:[userID] , почему? потомучто есть атомарность без транзакций и блокировок , тоесть db.addIfNotExist(videoId, userId), но появилась проблема , что появились популярные люди , их посты начали собирать по N млн лайков . На их форуме "профессионалы" ты всё правильно деалешь , но надо использовать bucket паттерн , я окей... но появилась еще проблема
2) использовав bucket паттерн поломалась пагинация , тоесть если бакеты все заполнены , то все отлично
10 | 10 | 10 | 10
но добавляем еще один лайк и создается новый бакет
1 | 10 | 10 | 10 | 10
И получается что если я возьму 1 бакет (отображаем на сайте самые новые), то выведется 1 запись , хотя можно больше .... "знаточки" предложили В КОДЕ while(count < pageSize) { db.loadMore} :D
3) попытался создать рекомендательную систему , для этого попытался с помощью механизма mongodb CreateView найти пересечения пользователей около 10 млн , и что вы думаете ? НЕ проворачивается , просто бесконечный (PS даже в JS такая операция пересечения пару секунд проворачивает)
Ладно про 3й пункт окей , но как быть в двумя первыми?
Нужная статья, но добавлю 5 копеек.
Для реляционных баз. что их не стоит применять для систем с большими потоками однотипных данных, пусть даже хорошо нормализованных. Индексирование снизит скорость вставки, а при недостатке ресурсов запросы будут работать очень медленно.
Нет информации о колоночной БД Apache Druid
Особенность колоночных баз, да и колоночных индексов в том, что для них невозможна операция промежуточной вставки или апдейта. Часто эти базы не предусматривают оператор UPDATE. Только DELETE и INSERT.
А где же про великую и ужасную DB2? Статья вполне интересная, хоть и для новичков.
Подобных статей много.
А вот как выбрать конкретную субд среди реляционных.. Вопрос на который нет ответа
Так они практчески имеют одинаковую производительность и одинакоые возможности. Конечно есть sqlite и h2 которые общем случае считаются менее пригодными для высоких нагрузок, но по факту есть много умельев которыен все далают на sqlite
Выбор конкретную СУБД из множества имеющихся на рынке - хорошая идея для отдельной статьи.
Не забываем и NewSQL базы. Очень впечатлил SingleStore (бывший MemSQL). Когда PG начал тупить, пришлось попробовать альтернативы. И я был приятно удивлен скоростью трехэтажных запросов, где PG просто заставлял идти делать чай между попытками заставить его паралелить запросы, ведь ему дали 40 ядер, а он использует одно.
Ещё есть тип геоданных и СУБД под них.
А вообще тренд идёт к тому, что у бывших реляционных СУБД появляются возможности для работы с NoSQL (или как ранее их называли неполно-структурированные данные) причем вполне эффективно.
А у NoSQL СУБД появляются возможности характерные для реляционных СУБД.
Потому с одной стороны можно сделать зоопарк из разных типов СУБД и это будет тяжело все поддерживать с тем учётом, что понадобится гораздо больше людей для обслуживания всех этих систем и разработчиков с нужными знаниями и опытом.
С другой стороны можно выбрать одну СУБД и правильно ее готовить и лишь в тех местах, где уже нельзя выжать больше-использовать другие виды СУБД, но только если это оправдано. Такое решение проще обслуживать и не нужно искать разрабов всех мастей по всем СУБД, достаточно будет несколько экспертов по каждому типу используемой СУБД.
И немаловажно при выборе СУБД да и вообще любой технологии ее распространение и доступность человеческих ресурсов в форме тех спецов, кто будет обслуживать и разрабатывать под эти СУБД (не по миру, а там где компания может себе позволить нанимать таких экспертов).
Часто можно встретить сложную систему из нескольких типов СУБД, где сложно что-либо дебажить или найти причину дефекта, равно как и обслуживать этот разросшийся хаос. Хотя на самом деле для таких решений достаточно было правильно настроить и правильно разрабатывать под один тип СУБД+ (очень редко) ещё один тип СУБД.
Спасибо за комментарий!
Да, верно про для работы с гео-данными есть специализированный тип СУБД - Spatial, я обязательно о нем напишу в следующей статье.
По поводу выбора одной СУБД для решения разных типов задач - вы правы, так можно делать, если это оправдано, но надо понимать, что скорее всего это будет компромисс. Как правило, те СУБД, которые "заточены" на работу с определенным типом данных\активностей, работают эффективнее, чем гибридные СУБД. При этом на небольших и средних нагрузках, скорее всего никто не заметит разницы, а вот при серьезных промышленных нагрузках, high-load'е, скорее всего разница в производительности будет ощутимой.
Во всем должен быть разумный подход. ))
И опять же в MS SQL Server есть тип данных geography.
Так что разделение СУБД по типам становится всё менее и менее актуально
На сегогдняшний день все более-менее продвинутые СУБД поддерживают большинство типов хранения данных.
Например, MS SQL Server. На сегодняшний день она и реляционная, и колоночная, и графовая.
Ну, ключ-значение даже не обсуждается.
А поддержка XML и JSON вполне позволяет отнести её и к документо-ориентированным.
Не упомянута и Cosmos DB, которая поддерживает API всех 5 типов.
Тема колоночных СУБД не раскрыта, нужны бы более наглядные примеры в статью.
Какую СУБД выбрать и почему? (Статья 1)