Вот я чего и боюсь, что узким местом станет сеть, connection pool, и т.д. То есть 6 млн. записей в час (т.е. 100 000 в минуту) на один физический сервер не пройдут. Шардинг — да, но это scale-out, а при том, что лицензия на каждую установку SQL Server стоит денег, это добавляет cost, помимо собственно железа. Поэтому именно для этой таблицы идея с SQL Server-ом мне не нравится.
Кроме того, обеспечить одновременно чтение и запись на одном сервере может оказаться невозможно. Нужно как-то отделять одно от другого. В MongoDB, например, мне нравится, что она может кешировать данные в памяти, занимая ее хоть всю. Это плюс.
В общем, разумнее всего — хранить обычные данные в обычной базе (MS SQL), а для данного случая копать распределенные базы.
База OLTP. Транзакции не нужны. То есть UPDATE-ов по этому делу вообще не будет, толко INSERT и SELECT. Команды, железа, лицензий пока нет, поэтому есть пока некоторая свобода выбора. В общем, пока задача — определить, что в принципе справится с такими данными и выбрать наименее затратный вариант.
Соображения безопасности. Отчет может содержать то, что пользователь не должен видеть. Поэтому мы выводим только ID отчета. К самим отчетам имеет доступ только тех-поддержка.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Кроме того, обеспечить одновременно чтение и запись на одном сервере может оказаться невозможно. Нужно как-то отделять одно от другого. В MongoDB, например, мне нравится, что она может кешировать данные в памяти, занимая ее хоть всю. Это плюс.
В общем, разумнее всего — хранить обычные данные в обычной базе (MS SQL), а для данного случая копать распределенные базы.