Плюсы и минусы использования MongoDB вместо MS SQL Server

Ответ 1

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

Прежде чем пытаться ответить на ваши вопросы, я должен сказать, что если MS SQL Server работает хорошо для вас, а затем придерживаться его. Вы не имеете упоминается любая действительная причина, ПОЧЕМУ вы хотите использовать MongoDB, за исключением факта что вы узнали об этом как документ, ориентированный на db. Более того, я вижу что у вас есть почти тот же набор метаданных, которые вы захватываете для каждая камера, то есть ваша схема динамическая.

• чтобы указать, хорош ли MongoDB для хранения таких данных, которые в конечном итоге будут запрашиваться в отношении временных диапазонов (например, получить все изображения конкретной камеры в течение определенного часа)? Любые предложения по дизайну схемы на основе документов для моего случая?

MongoDB, являющийся ориентированным на документ db, хорошо подходит для запроса внутри агрегата (вы называете его документом). Поскольку вы уже сохраняете данные каждой камеры в своей собственной таблице, в MongoDB у вас будет отдельная коллекция, созданная для каждой камеры. Вот как вы выполняете запросы диапазона дат.

• Какими должны быть спецификации сервера (CPU, RAM, Disk)? любое предложение?

Все базы данных NoSQL построены для масштабирования на товарном оборудовании. Но, кстати, вы задали вопрос, вы можете подумать о повышении производительности с помощью масштабирования. Вы можете начать с разумной машины, и по мере увеличения нагрузки вы можете продолжать добавлять больше серверов (масштабирование). Вам не нужно планировать и покупать серверы высокого уровня.

• Должен ли я рассматривать Sharding/Replication для этого сценария (при одновременном рассмотрении производительности в письменной форме для синхронизации наборов реплик)?

MongoDB блокирует весь db для одной записи (но дает другие операции) и предназначен для систем, которые имеют больше чтений, чем записи. Так что это зависит от вашей системы. Существует несколько способов очертания и должно быть специфичным для домена. Общий ответ невозможен. Однако некоторые примеры могут быть даны как осколки по географии, по отраслям и т.д.

Также читайте Простой английский ввод в CAP-теорему

Обновлен с ответом на комментарий о sharding

В соответствии с их документацией, вам следует рассмотреть возможность развертывания кластерного кластера, если:

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

Итак, основываясь на последнем пункте да. Функция автоматического масштабирования построена для масштабирования записей. В этом случае у вас есть блокировка записи на каждый осколок, а не на базу данных. Но мой теоретический ответ. Я предлагаю вам обратиться за консультацией к группе 10gen.com.

Ответ 2

чтобы сказать, хорош ли MongoDB для хранения таких данных, что в конечном итоге будут запрашиваться в отношении временных диапазонов (например, получить все изображения конкретная камера между указанным часом)?

Это слушание слишком субъективно для меня. Из личного опыта с многочисленными решениями SQL (по иронии судьбы, не MS SQL) я бы сказал, что они одинаково хороши, если все сделано правильно.

также:

Какими должны быть спецификации сервера (CPU, RAM, Disk)? любое предложение?

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

Что касается схемы, я бы пошел за документом структуры:

{
    _id: {},
    camera_name: "my awesome camera",
    images: [
        { 
            url: "http://I_like_S3_here.amazons3.com/my_image.png" ,
            // All your other fields per image
        }
    ]
}

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

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

Должен ли я рассматривать Sharding/Replication для этого сценария (учитывая производительность в письменной форме для синхронизации наборов реплик)?

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

Существуют ли какие-либо преимущества использования нескольких баз данных на одном компьютере, так что одна база данных будет содержать изображения текущего дня для всех камер, а вторая будет использоваться для архивации изображений предыдущего дня?

Несмотря на то, что блокировка записи MongoDBs находится на уровне DB (в настоящее время), я бы сказал: Нет. Правильная структура документа и правильная настройка/репликация (если необходимо) должны иметь возможность обрабатывать это в одной коллекции (основанных на документе) под одной БД. Не только это, но вы можете направлять записи и читать в кластере на определенные серверы, чтобы создать ситуацию concurrency между определенными компьютерами в вашем кластере. Я бы продвигал правильное использование функций MongoDBs concurrency через разделение БД.

Изменить

После того, как я снова прочитал вопрос, я пропустил из своего решения, что вы вставляете изображения 80k + для каждой камеры в день. Вместо этого, вместо встроенной опции, я бы сделал строку для каждого изображения в коллекции под названием images, а затем в коллекции camera и запросил два, как в SQL.

Облицовка коллекции images должна быть такой же простой на camera_id.

Также убедитесь, что вы принимаете во внимание ваш рабочий процесс с вашим сервером.

Ответ 3

чтобы сказать, хорош ли MongoDB для хранения таких данных, что в конечном итоге будут запрашиваться в отношении временных диапазонов (например, получить все изображения конкретная камера между указанным часом)? Любые предложения о Дизайн схемы на основе документов для моего случая?

MongoDB может это сделать. Для повышения производительности вы можете установить индекс в своем поле времени.

Какими должны быть спецификации сервера (CPU, RAM, Disk)? любое предложение?

Я думаю, что RAM и Disk будут важны.

• Если вы не хотите делать sharding до scale out, вам следует рассмотреть больший размер диска, чтобы вы могли хранить в нем все свои данные.
• Ваши горячие данные должны помещаться в вашу оперативную память. Если нет, тогда вы должны рассмотреть большую ОЗУ, поскольку производительность MongoDB в основном зависит от ОЗУ.

Должен ли я рассматривать Sharding/Replication для этого сценария (while учитывая производительность в письменной форме для синхронизации наборов реплик)?

Я не знаю, сколько у вас камер, даже 1000 вставных/секундных файлов с 1000 камерами все еще должно быть легко MongoDB. Если вы относитесь к производительности вставки, я не думаю, что вам нужно сделать обход (за исключением того, что размер данных слишком велик, чтобы вы могли разделить их на несколько машин).

Другая проблема - частота чтения вашего приложения. Это очень высоко, то здесь вы можете рассмотреть осколки или репликации. И вы можете использовать (timestamp + camera_id) в качестве вашего ключа окантовки, если ваш запрос доступен только на одной камере в диапазоне времени.

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

Вы можете разделить таблицу на две коллекции (archive и current). И установите индекс только на archive, если вы только запрашиваете дату на archive. Без накладных расходов на создание индекса коллекция current должна иметь преимущество при вставке.

И вы можете написать ежедневную программу, чтобы сбрасывать данные current в archive.