Когда мы рассказывали о базах данных, то упомянули, что нет универсальной базы на все случаи жизни — всё зависит от того, что там хранить и как с этими данными надо работать. Настало время копнуть поглубже и выяснить, какие базы данных лучше подходят для разных задач.
Коротко про базы данных
База данных — это хранилище информации, структурированной и не очень. Обычно так называют множество связанных таблиц, хотя на практике данные могут представляться в совершенно разном виде. Ещё различают БД и СУБД, хотя во многих базах грань между ними часто очень тонкая.
Базы данных (БД) — это набор данных, организованных каким-то способом. Например, если у вас в квартире есть гардеробная или кладовка, то всё это помещение со всем её содержимым может считаться базой (но не данных, а вещей или банок с огурцами, что не меняет сути).
Система управления базой данных (СУБД) — это когда семья села за стол и самого младшего отправляют в кладовку за огурцами, он приносит банку и не разбивает по дороге. То есть СУБД — это какое-то средство для манипуляции данными в базе, например программа.
Ключевая задача каждой базы данных — работа с очень большим объёмом данных и от лица большого числа пользователей (и часто одновременно).
А вот картинка, которая пригодится для общего понимания:
Реляционные базы данных
Типичные представители: MySQL, PostgreSQL, SQLite, Oracle.
Реляционные базы данных ещё называют табличными, потому что все данные в них можно представить в виде разных таблиц. Реляционная БД напоминает телефонную книжку, где все данные заносятся в таблицу и относятся к какому-то типу данных (Ф. И. О., номер, адрес и так далее). Для управления реляционными БД в основном используется язык запросов SQL.
Главный плюс таких баз данных — структурированность: всё лежит на своём месте, записи связаны друг с другом и в них можно хранить большой объём однотипной информации. Связь обычно происходит по ключевому полю, а в случае записной книжки это может быть номер телефона. Например, если мы знаем адрес человека, но не знаем, как его зовут, то находим адрес, смотрим, какой номер телефона с ним связан, и по этому номеру сразу находим имя.
Преимущества. В SQL-базах строго определены типы данных и связи между разными элементами. Это позволяет создавать сложные запросы, а ещё загружать и редактировать нужные данные в нескольких таблицах одновременно.
Недостатки. Если структура и связи в базе данных изначально спроектированы плохо, это может снизить скорость доступа и общую скорость работы с базой данных. Бывает так, что база создавалась под простые задачи, потом со временем разрослась и нужно бы её переструктурировать, но это сложно — нужно тогда и переписать весь код, который с ней работает. А ещё реляционные базы не очень подходят для горизонтального масштабирования.
Нереляционные базы данных (всё остальное)
Все базы, где данные не структурированы или структурированы частично, называются нереляционными (NoSQL). Их много, мы поговорим про самые популярные.
Колоночные
Типичные представители: ClickHouse, Apache Cassandra, HBase.
Колоночные базы по своей логике похожи на реляционные — информация тоже хранится в табличном виде, но приоритет отдаётся столбцам, а не строкам.
В реляционной БД нужно пройтись по всей строке, чтобы добраться до нужной ячейки. В колоночной же достаточно знать индекс колонки, поэтому доступ к элементу моментальный. Это значит, что запросы непоследовательных данных обрабатываются в реальном времени и без задержек.
Колоночные базы данных лучше всего применять в сложных аналитических задачах, где количество строк достигает сотен миллионов. Например, ClickHouse придумали в Яндексе для хранения и работы с данными Яндекс Метрики — а это огромное количество записей, которые обновляются каждую секунду.
Преимущества. Производительность не теряется на больших объёмах, а правки в структуру вносятся почти мгновенно. Ещё в таких базах можно сжимать данные для экономии памяти.
Недостатки. Колоночные БД относительно медленно работают на запись, поэтому они плохо подходят для транзакционных систем, например банковских записей.
Графовые
Типичные представители: Neo4j, InfoGrid, JanusGraph.
Эти базы данных основаны на теории графов, отсюда и их название. Граф в математике — это когда есть много точек (узлов), которые соединены между собой множеством линий (графов). Если мы возьмём, например, 15 своих знакомых, обозначим каждого из них за точку, и соединим одним цветом тех, кто знает друг друга лично, а другим — заочно, мы получим граф.
В графовых БД всё работает точно так же — есть узлы, в которых хранятся данные, и есть графы, которые эти узлы соединяют. Можно хранить связи между узлами, соединяя их рёбрами. А ещё там рёбра могут быть взвешенными и иметь какое-то числовое значение, например насколько сильно связан один узел с другим.
Типичные задачи графовых баз:
- оптимизация логистических маршрутов;
- вычисление подозрительных банковских транзакций;
- поиск и рекомендация друзей в соцсетях.
Преимущества. В таких базах можно создать и поддерживать любые структуры данных. Также легко установить связи даже между отдалёнными узлами (например, в примере про знакомых связь между вами и онлайн-репетитором двоюродной тёти брата мужа подруги, которая училась с вашей сестрой в одном классе).
Недостатки. Минусов как таковых нет, просто сами графы уместны далеко не всегда. В графовых БД нет стандартизированного языка запросов, поэтому придётся изучать SPARQL и модель RDF. Выглядит это примерно так:
Резидентные
Типичные представители: Redis, Memcached, Couchbase Server.
В резидентных базах данные хранятся по принципу «ключ — значение», как в словарях в Python. Каждому ключу соответствует определённое значение любого типа. Значения могут повторяться, ключи — нет, они уникальны. Но на самом деле резидентные базы редко используются сами по себе. Чаще они дополняют SQL-хранилища, чтобы транзакции в последних проводились быстрее.
Преимущества. Простая схема организации данных, а также возможность апгрейда менее шустрой SQL-базы.
Недостатки. Слабое место резидентных баз — объём оперативной памяти, потому что они загружаются туда полностью. Если памяти недостаточно, данные уходят в файл подкачки, и производительность становится хуже, чем в реляционных базах. Ещё при неправильной организации всё может сломаться, потому что в резидентных БД на первом месте стоит скорость работы, а не целостность данных.
Документоориентированные
Типичные представители: MongoDB, CouchDB.
В таких базах данных каждая запись — это документ. Для удобства работы документы собираются в коллекции и тоже используют пары «ключ — значение». В этом документоориентированные базы похожи на резидентные, только данные хранятся не в таблицах, а в файлах JSON.
Преимущества. Нет требований к структуре данных — это просто наборы документов. А ещё такие БД легко обрабатывают любые объёмы информации (десятки и сотни гигабайтов) за раз.
Недостатки. У них свой язык запросов, отличный от SQL, правда, они поддерживают SQL-транзакции, что иногда выручает.
Ещё по теме
Вы здесь → Виды баз данных
