Стоит ли разбивать базу данных NoSQL на отдельных серверах?

Question

Мы все еще находимся на ранних этапах определения того, будем ли мы использовать RDBMS или NoSQL.

Одна из областей, представляющих интерес, если мы пойдем с NoSQL (вероятно, CouchDB, хотя мог бы быть MongoDB), будет ли разделение базы данных NoSQL на разных серверах лучше, чем один экземпляр сервера NoSQL?

Мы будем создавать систему управления файлами, в которой определенные файлы / видео будут группироваться на разных серверах. Файлы / видео, связанные с учетными записями, будут храниться на сервере учетных записей и т. Д. Чтобы запросить файл, связанный с учетными записями, мы, скорее всего, будем искать в базе данных на сервере учетных записей.

В будущем я вижу, что кто-то скажет: «Почему я не могу найти на всех серверах тип файла или видео»?

Очевидно, что здесь лучше иметь одну базу данных. Однако, кроме задержки в запросах http для запросов к серверам, существуют ли лучшие способы сделать это или плюсы и минусы большой базы данных?

JD

Answer 1

Идея (большинства) продуктов NoSQL заключается в том, что они обеспечивают горизонтальную масштабируемость. Это означает, что ваш единственный логический экземпляр может быть на десятках серверов. Например, в MongoDB вы можете использовать auto-sharding . Для вашей программы это абсолютно прозрачно: ваш код (почти) тот же, что вы использовали бы для одного сервера базы данных, но данные находятся, скажем, на 5 серверах.

Есть много плюсов: у вас есть центральное место для администрирования вашей базы данных, вы можете при необходимости запрашивать все базы данных, вам не нужно возиться с несколькими соединениями БД в вашем коде, БД автоматически балансирует эти коллекции которые должны быть сбалансированы, операции преобразования / сокращения могут выполняться параллельно, если это позволяет запрос и т. д.

Самые важные для меня: не слишком много административных затрат, и вам не нужно слишком много думать об этом сейчас , потому что вы можете добавить авто-шардинг позже.

Я бы не стал заниматься осколками, потому что он заново изобретает колесо, и это тоже нелегко. Во-первых, это был один из ключевых драйверов для NoSQL.