Категория > Новости > Не кринж, а база. Выбираем базу данных для своего проекта - «Новости»
Не кринж, а база. Выбираем базу данных для своего проекта - «Новости»10-09-2023, 13:43. Автор: Герман |
Зачем вообще выбирать базу данных? Почему нельзя просто взять ту, с которой уже работал, и использовать ее? Часто это оправданный выбор, но для чего же тогда создано почти 500 разных СУБД? Давай попробуем разобраться вместе, чем они отличаются и когда нужны. Традиционно все существующие СУБД делят на два класса: реляционные и нереляционные (Relational, NoSQL). В свою очередь, нереляционные СУБД можно разделить еще на 15 категорий — по моделям хранения данных. 485 реализаций СУБД, разбитых по категориям и лицензиям распространения Для упрощения нашей задачи есть смысл каждую из этих категорий отнести к СУБД общего или специального назначения. Терминология неофициальная — она используется просто для понимания того, что СУБД специального назначения будут хорошим выбором, если есть соответствующий запрос. Например, если предстоит много работать с временными рядами или координатами. СУБД общего и специального назначения Стоит отметить, что сегодня многие популярные СУБД поддерживают мультимодельное представление данных, то есть их можно отнести сразу к нескольким категориям. Более того, поскольку многие проекты активно развиваются, в них добавляется поддержка все новых функций и возможностей, в результате чего они становятся все больше похожи друг на друга. Так, сегодня множество NoSQL СУБД имеют поддержку и Поддержка синтаксиса SQL некоторыми NoSQL-проектами — это приобретенная функция, а изначально такие СУБД проектировались совсем для других целей. Например, повсеместное использование
Дополнительные критерииКроме первичной модели хранения данных, при выборе СУБД стоит обратить внимание и на другие параметры.
Вторичные модели хранения данныхМногие современные СУБД поддерживают несколько моделей хранения данных. Например, в PostgreSQL, MySQL и других распространенных СУБД можно создавать отдельные коллекции для хранения документов в формате JSON, что позволяет сохранять данные уже сейчас, а со схемой хранения разбираться потом. А большинство распространенных коммерческих СУБД поддерживают работу с пространственными данными. Комбинации моделей хранения могут быть совершенно произвольными.
Поддерживаемые языки программированияЧтобы не обрекать себя на поиск обходных путей и прикручивание костылей, лучше сразу убедиться, что СУБД поддерживает выбранный тобой язык программирования.
Методы репликацииРепликация данных в реальном времени спасет нас в случае потери основной базы данных, а также поможет распределить нагрузку за счет переноса части запросов на реплики. На уровне СУБД репликация может быть физической или логической. Физическая репликация основывается на том, что операции, содержащиеся в логах БД, выполняются на репликах. Репликация может быть синхронной или асинхронной. Асинхронный метод отличается тем, что всегда есть набор транзакций, завершенных на основной базе, но еще не дошедших до резервной. В случае перехода на резервную базу при сбое основной эти транзакции будут потеряны. Этот метод подойдет, если для нас производительность имеет максимальный приоритет. При синхронной репликации завершение операции В случае же, когда в максимальном приоритете доступность данных, можно настроить режим синхронной репликации. Но если реплика не отвечает, то репликация переключается в асинхронный режим, а как только связь восстанавливается — реплика сразу обновляется до актуального состояния. Логическая репликация — это когда изменения в БД происходят в результате вызовов ее API, например в ходе выполнения SQL-запросов.
Поддержка MapReduce APIЕсли база данных хранит информацию в распределенной среде, то есть данные разделены и содержатся на нескольких узлах, то наличие API для MapReduce позволяет выполнять вычисления MapReduce непосредственно на данных внутри базы без необходимости извлекать их наружу. Основная идея MapReduce заключается в распределении решения задачи на множество узлов, где каждый узел выполняет локальные вычисления, а затем результаты агрегируются и объединяются для получения окончательного итога. Это сокращает время передачи данных между узлами и повышает производительность.
Концепции согласованности в распределенных БДВ контексте распределенных систем согласованность данных имеет особое значение из‑за возможности существования нескольких реплик данных или узлов, которые могут изменять данные асинхронно. Задача состоит в том, чтобы гарантировать, что данные синхронизированы и согласованы на всех узлах системы в определенный момент времени. Согласованность данных бывает следующих типов. Слабая согласованность (Weak Consistency): при слабой согласованности система не гарантирует мгновенное распространение изменений и согласованное состояние данных между узлами. Вместо этого система может допускать временные расхождения или конфликты данных. Это обеспечивает высокую доступность и масштабируемость в распределенных системах, но может приводить к несогласованности данных в определенных ситуациях. Сильная согласованность (Strong Consistency): при сильной согласованности система гарантирует, что данные всегда находятся в согласованном состоянии между различными узлами в системе. Это означает, что любое чтение данных будет учитывать последние изменения, сделанные в системе. Часто для достижения сильной согласованности требуется дополнительное время и ресурсы. Последовательная согласованность (Sequential Consistency): при последовательной согласованности система гарантирует, что все операции записи и чтения будут выполняться в строгом порядке, как будто они осуществляются последовательно. Это означает, что результаты операций будут соответствовать некоторому линейному порядку, независимо от параллельности их выполнения. Причастная согласованность (Eventual Consistency): это свойство означает, что при отсутствии новых обновлений данные в итоге будут согласованы. В этом случае база данных не гарантирует мгновенной согласованности между копиями данных, но с течением времени все копии будут согласованы. Это обычно достигается путем асинхронного распространения обновлений и их слияния на разных узлах базы данных. Каузальная согласованность (Causal Consistency): в этом режиме база данных гарантирует, что если операция A зависит от операции B, то операция A будет учитывать результаты операции B или более поздние результаты. Это обеспечивает согласованность данных с учетом их причинно‑следственных связей.
Концепции транзакцийКонцепции транзакций обеспечивают атомарность, согласованность (в контексте транзакций «согласованность» имеет другое значение), изолированность и долговечность операций. Одной из концепций транзакций в базах данных является ACID (Atomicity, Consistency, Isolation, Durability). ACID — это классический набор свойств транзакций в базах данных:
Другая концепция называется BASE (Basically Available, Soft state, Eventually consistent). Она отличается от ACID и обычно используется в распределенных системах, где в приоритете высокая доступность и масштабируемость, а согласованность может быть нестрогой.
Возможность работы с данными в оперативной памятиЭта полезная опция разрешает хранить некоторые или вообще все данные в оперативной памяти, которая, как известно, гораздо быстрее постоянной. Может быть очень удобно, например, для получения операционной аналитики, когда выполнение аналитических запросов требует обработки большого объема данных в режиме реального времени. Таким образом можно быстро анализировать информацию и получать сводные результаты для принятия оперативных решений. Перейти обратно к новости |