Доброго времени суток!

Необходима помощь в выборе СУБД на стороне Back-End для одного проекта.
Немного погуглил на тему "How to choose database" и т.п., но проблема в том, что слишком слабо знаю особенности разных СУБД.
Поэтому решил обратиться на форум за помощью.

Проект представляет, по сути, интернет-сервис, весь Back-End на нашей стороне, поэтому пользователи с БД явным образом не взаимодействуют.

Основные критерии:
- Не имеет значения, SQL или NoSQL
- Не Oracle DB
- Должна быть возможность взаимодействия с СУБД через C# (.NET)
- Важна масштабируемость, т.к. непонятно кол-во пользователей - возможно, 1 000, а, возможно, 1 000 000
- На стороне Back-End не храним media-контент (ни музыки, ни видео - возможно, немного небольших картинок, не более)
- Важна быстрая обработка запросов и получение результатов (нет возможности ждать лишних 10-20-40 секунд, т.к. проект ориентирован на обычных пользователей, а ждать они не любят)
- Соотношение типов запросов будет примерно таким: Number of SELECT > Number of UPDATE > Number of INSERT
//использую термины SQL, но имею в виду получение результата из БД, обновление уже существующих записей и добавление новых записей

Т.к. я являюсь новичком в сфере DBA, просьба как-то аргументировать предлагаемые варианты, чтобы было понимание : )

Немного поизучав БД, пришёл к выводу, что можно использовать MySQL/PostgreSQL или MongoDB (последняя как раз должна прекрасно масштабироваться).

И еще один вопрос - на какие еще вопросы обычно необходимо отвечать (самому себе) при выборе СУБД для проекта?

Заранее спасибо!

SERG1257авторИ еще один вопрос - на какие еще вопросы обычно необходимо отвечать (самому себе) при выборе СУБД для проекта?
Какую СУБД знает ваш базист?
Какой бюджет, если базиста нет?

Логичный вопрос)
По сути, мы уже настроились изучать СУБД "с нуля"/практически с нуля, т.к. есть возможность потратить время на это.

Dimitry SibiryakovIgor MakaryevПо сути, мы уже настроились изучать СУБД "с нуля"/практически с нуля,
т.к. есть возможность потратить время на это.
Это будет ваш личный проект, т.е. заказчика как такового нет?


Да, именно : )
Поэтому мы вольны не торопясь, основательно подойти к выбору всех необходимых инструментов - и потратить какое-то время на их освоение ради конечного результата.
Но, допустим, потратить условно месяц на выбор СУБД, подняв экземпляр каждой, погоняв на прототипе, измерив производительность - это всё же слишком, поэтому решил обратиться сюда. То есть время есть, но в разумных пределах - как и всегда в нашей жизни, впрочем : )

Dimitry SibiryakovХотя нет, я неправ.

Igor Makaryev- Должна быть возможность взаимодействия с СУБД через C# (.NET)

Вот этим пунктом ваш список низводится до одной позиции - MS SQL. Больше ни с чем этот
..NET нормально взаимодействовать не умеет.


Сразу несколько вопросов возникло.

1. Нулевой пункт - как раз "Какую СУБД знает ваш базист?", я правильно понимаю?

2. Хм, почему не умеет? Та же MongoDB:
http://en.wikipedia.org/wiki/MongoDB
"There are REST and HTTP interfaces that allow the manipulation of MongoDB entries via HTTP GET, POST, UPDATE, and DELETE calls."
"Имеется подробная и качественная документация, большое число примеров и драйверов под популярные языки Java, JavaScript, Node.js, C++, C#, PHP, Python, Perl, Ruby, Grails&Groovy."

Вроде всё в порядке. Примерно такое же я видел про каждую БД, о которых читал, - MySQL, PostgreSQL и т.п. - везде есть нужные библиотеки/драйвера/API.

3. "С описанной задачей справится любая в умелых руках." - хм. А та же масштабируемость? Собственно, изначально мы и задумались над тем, что надо уходить от MS SQL Server, т.к. плохо масштабируется и на большом количестве данных/запросов можем встрять так, что придётся переходить на другую БД - только слишком поздно.

Или, например, статья, которую изучал до того, как задал вопрос здесь:
http://nosql.findthebest.com/l/1/MongoDB

"Best Use: frequently written, rarely read statistical data"
Меня это смутило, т.к. как раз читать будем чаще, чем писать.

pkarklinIgor Makaryev задумались над тем, что надо уходить от MS SQL Server, т.к. плохо масштабируется и на большом количестве данных/запросов можем встрять так, что придётся переходить на другую БД - только слишком поздно.

Чем, интересно, тут думали?!

Ммм, я понимаю, что, бесспорно, гораздо проще написать одно слово "facepalm", нежели объяснить, где ошибка.

Dimitry SibiryakovIgor MakaryevСразу несколько вопросов возникло.
Сразу несколько ответов:
1) Нулевой пункт "Которая уже есть у заказчика", поскольку под неё предполагается и
наличие инфраструктуры, включая DBA.
2) Заявленная способность работать и наличие .NET провайдера не означают, что оно будет
работать хорошо и возможности СУБД будут использованы на 100%.
3) Масштабируемость делается умелыми руками в виде шардинга и прочей кластеризации.


1. Логично

2. Хм, да, понимаю.

3. Окей, но разве тот же MS SQL поддерживает шардирование?

SERG1257Igor Makaryev По сути, мы уже настроились изучать СУБД "с нуля"/практически с нуля, т.к. есть возможность потратить время на это. Тогда приоритет должен быть у мэйнстрима.
Непонятно неприятие Oracle. Условия задачи заточены под MSSQL - ну так берите и работайте или вы благословения ждете.
Хотите потыкать в NoSQL - дело ваше, но мое мнение это нишевое решение.

А что есть мэйнстрим?)
Вы имеете в виду SQL?

По сути да, ждём. Почему, например, тот же Twitter / Facebook использует MySQL, а не MS SQL? У них же и сайты не IIS держит, а какой-нибудь ngnix - полагаю, по тем же причинам: виндовые решения кушают уж очень много, а работают помедленнее.
Возможно, я не прав - тогда просьба пояснить, где я не прав и куда копать : )

А в каких случаях вы бы рекомендовали обратиться к NoSQL? Ответ на какой вопрос должен привести к этому выбору?


P.S. да, у нас опыт есть как раз в использовании MS SQL. И работаем, по большей части, с ним. Но опыта работы с MS SQL в условиях больших нагрузок не было - довольно скептически относимся к использованию данного решения при большом кол-ве запросов, отчего и решили покопать в сторону других СУБД.

Dimitry SibiryakovIgor Makaryevразве тот же MS SQL поддерживает шардирование?
Шардирование это в простейшем случае распределение разных данных по разным серверам с тем,
чтобы пользователи, работающие с разными данными обслуживались, соответственно, разными
серверами. Поддержка со стороны СУБД тут никакая не нужна, достаточно соответствующе
запрограммировать клиентскую/апп-серверную часть.


Ага.
Примерно представил.
То есть на одном шарде я храню одни данные (таблицы), на другом - другие. И обращаюсь, соответственно, к нужному шарду.
А как быть в случае, когда бОльшая часть таблиц связана друг с другом (в реляционной БД)? Получается, что на каждом шарде должны быть две одинаковые полновесные БД, а вот обращаться, допустим, за Table1 мы будем к Shard1, а за Table2 - к Shard2, тогда нагрузка будет балансироваться. Но операции изменения записей и добавления придётся делать на каждом шарде.
Или я неправильно рассуждаю?

P.S. хотя у MySQL есть auto-sharding, когда одна таблица "размазывается" по нескольким нодам кластера БД:
http://www.mysql.com/products/cluster/scalability.html

P.P.S. задумался, а есть ли у MS SQL Server классическая кластеризация с балансировкой нагрузки? Есть Failover Cluster - с зеркализацией..

kdvIgor Makaryevнепонятно кол-во пользователей - возможно, 1 000, а, возможно, 1 000 000
не говорите так никому. Под "пользователями" обычно имеется в виду количество одновременных коннектов к чему-то, к СУБД или веб-серверу. Поэтому "миллион одновременных пользователей", особенно в клиент-сервере - это ересь. Кроме того, в случае веб-интерфейса к СУБД обычно используют пул коннектов, так что тут "пользователей" тем более нет.
Еще можно в качестве "количества" назвать количество пользователей сервиса. Но это малоинтересно, если их будет миллион, а в день будут заходить на сервер всего 10 человек.

Хорошо, спасибо за замечание!
Но вообще я, в принципе, в виду как раз миллион активных пользователей.
Сколько человек пользуются eBay? Думаю, что миллион запросов у них случается)
За терминологию еще раз спасибо, учту!

SERG1257Igor Makaryev А в каких случаях вы бы рекомендовали обратиться к NoSQL? Когда не требуется поддержка ACID. или другими словами когда в данных не содержатся денег. Пропажа (пусть и ОЧЕНЬ маловероятная) комментария, лайка или ч.л. подобного не так неприятна, как пропажа денег.
Ну и про Специалиста вам очень верно заметили. Все реляционные СУБД на данный момент - продукт зрелый, и если у вас что-то не получается, то это вы не умеете его готовить. А вот за NoSQL я такого не скажу.

Ммм, в принципе, мы вполне можем "потерять" "лайк".
Проект не является каким-нибудь аукционом, где потеря транзакции приведёт к потере денег.
Про специалиста - понимаю, но хотим реализовать проект собственными силами.

kalimbaDimitry Sibiryakovпропущено...

Шардирование это в простейшем случае распределение разных данных по разным серверам с тем,
чтобы пользователи, работающие с разными данными обслуживались, соответственно, разными
серверами. Поддержка со стороны СУБД тут никакая не нужна, достаточно соответствующе
запрограммировать клиентскую/апп-серверную часть.
Вы не совсем правы : ) В SQL Azure пошли дальше . Хотя в приложении конечно в любом случае надо будет обрабатывать.

Igor Makaryev,
Крайне рекомендую прочесть Вам книгу NoSQL Distilled и/или 7 databases in 7 weeks (обе есть на русском), я думаю после их прочтения вам будет понятней разница подходов. По поводу критики NoSQL на хабре недавно была статья , тоже советую к прочтению.

Да, есть несколько СУБД, которые поддерживают шардирование, что называется, "по свою сторону баррикад".
К тому же разряду относится MongoDB со своим auto-sharding: http://docs.mongodb.org/manual/core/sharding-introduction/

За книги огромное спасибо, постараюсь изучить!
А статью да, на днях читал : )
Вот, кстати, по ней же вопрос - касательно шардирования. Вроде шардирование - "распределение разных данных по разным серверам". Окей. Но при этом в статье говорится о том, что "информация должна разойтись по всем нодам кластера" - зачем, если вроде храним разные данные отдельно?

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

Смотрел.
По сути, пожалуй, ближе всего ко всяким Facebook, Twitter (Front-End <-> Back-End) без необходимости хранить тонны переписок и медиа с быстрым клиентом на стороне пользователя, с простыми query.
Twitter, Facebook используют MySQL, eBay - Oracle Database.

DPH3Igor Makaryev,

1) Если вообще не знаете SQL, то или MS SQL (так как он уже хорошо поддерживается студией) или Mongo (так как она как раз для программистов, не сумевших освоить реляционные СУБД). Впрочем, в случае MS SQL большую часть сложности возьмет на себя ORM.

2) Не думайте о масштабировании. Если ваш личный проект взлетит - то сможете поменять подход. Но шансов, что вы вылезете в течении нескольких лет за пределы MS SQL разумных редакций - весьма невелики.

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

1) То есть предлагаете просто работать с одиночным instance-ом MS SQL? (ну, в крайнем случае завести FailoverCluster для надёжности)

2) Вот как раз решили задуматься с самого начала над тем, чтобы не пришлось переписывать.. Возможно, действительно лучше сделать на MS SQL, а затем, если возникнет необходимость, смигрировать на другую СУБД.

3) Хм, а почему невозможно?
Потеря данных не сверхкритична (всё же не банковская система), а вот доступность важна (собственно, выше я писал про пользователей).