Документо-ориентированные

Записаться

Следующий большой класс - это документоориентированные базы данных. Впервые столкнувшись с данными базами, разница практически не заметна, потому, что документоориентированные базы данных тоже обещают работу с неструктурированными базами данных, с данными, у которых структура очень часто меняется. При этом все данные структуры объекта или документы, как они его называют, они хранятся внутри самой ячейки одной, а мы можем доступаться к ним через языки запросов и стандартные операции баз данных, что уменьшает количество join-ов, но при этом структура документов не должна быть известна заранее, может изменяться динамично, при этом запросы все равно должны понимать содержимое документа, если там есть такое поле, то как к нему обращаться, что из него получать внутри документа, если есть у нас такой атрибут и такое поле.

Приложения, для которых лучше всего подходит это быстрое сохранение - доставка для динамично изменяющихся схем данных и объектов. Наиболее популярный и известный представитель данного вида - это MongoDB, объекты, которые называются документы, хранятся в BSON виде, это переведенный в двоичный вид JSON структура, документы объединены в коллекции, но в одной коллекции, дальше это будет показано, документы могут иметь абсолютно разную структуру. Файлы в данной базе данных могут быть отображены в память, что ускоряет работу с ней. Индексы у нас внутренние, операции обработки реализуются с использованием MapReduce, и реализуется высокая степень доступности как на запись, так на чтение. Из этого мы лучше подробнее скажем на следующих слайдах.

Можем сказать, что реализовано на C++, но имеет драйверы и api во множество языков и баз данных, как стандартных, так и набирающих популярность. Мы, наверно, уже об этом говорили, но нелишним будет повторится, провести различия между репликацией данных и шардингом. Репликация - это когда мы данные копируем и поддерживаем копию достаточно синхронной с каким-то выделенным сервером, мастером, и данный подход очень сильно ускоряет чтение, потому что читать мы данные можем параллельно из разных мест, то есть из копий. При этом операция записи у нас должна записать или синхронизировать свои значения со всеми нашими репликами, и это отнимает ресурсы, то есть операция записи замедляется. Шардинг не гарантирует, что мы в каждом узле найдем блок от наших искомых данных, поэтому должны обращаться в выделенный сервер, NameNote, он нам укажет на DataNote, где наш блок лежит. Чтение будет все равно параллельно, потому что блоки распределены равномерно по разным серверам, оно будет быстро достаточно, но сама операция обращения к NameNote достаточно узкое место. При этом, если мы пишем, мы пишем снова параллельно в разные сервера, и таким образом оптимизируем чтение, у нас нет необходимости синхронизовать многие копии между собой. Обычно стандартное значение по умолчанию повторения или копирования блока - это троечка. MongoDB реализует как шардинг, так и репликацию. Честно говоря, здесь можно, наверное, только представлять детали того, как именно это реализуется, если я правильно понимаю, то когда мы заводим сервер, мы каким-то образом говорим ему, это DataNote, который используется в чистом виде для шардинга, или это какой-то Note, который хранит только реплику какого-то из DataNote.

Пример операции над данными в MongoDB. Мы видим, что два документа с разной структурой, есть совпадающие поля и могут быть абсолютно не совпадающие поля, могут храниться в одной коллекции. Операции, которые мы делаем над данной коллекцией, будут работать только с теми документами, в которых есть те поля, к которым мы обращаемся в нашем запросе. Дальше простейшие операции ставки документа, поиска документа, как множества, так и единичного документа, операция update, операция удаления и операция явного обновления индекса. Все достаточно просто, и, вообще, простота - это именно тот фактор, на который в первую очередь клюют разработчики при переходе на новый SQL. Да, они понимают, что они теряют, уходя от реляционных баз, но первое, с чем они сталкиваются это то, что гораздо меньше усилий нужно на создание самих хранилищ, задание там структуры, и я думаю, что очень большое значение имеет именно психологический фактор, когда разработчик или проектировщик берет на себя риск, что структура данных будет именно такой, если поменяется, то незначительно, и при этом не нужно будет перестраивать всю структуру баз данных или терять какие-то части, или терять индексы и так далее. Эта головная боль снимается практически при использовании всех NoSQL баз, они не требуют задавать структуру, а сразу предоставляют возможность работать с данными, никак не ограничивая в будущем.