Используется ли в вашем проекте более одной БД

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

А сохранность данных значение имеет? Если имеет, то монго тоже фтопку вместе с кассандрой.

Будете использовать несколько БД?

Если для части данных нужна ACID семантика, то буду использовать несколько бд.

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

Ну я не отрицал что они есть )

А сохранность данных значение имеет? Если имеет, то монго тоже фтопку вместе с кассандрой.

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

Про монгу вот http://hackingdistributed.com/2013/01/29/mongo-ft/

Про кассандру и так всё очевидно.

У нас в проекте даже более двух БД используется :)

Реклама HyperDex? Не эксперт в Mongo/Cassandra/HyperDex, но я думаю суть поста вы уловили. Причем написать полблога не зная о WriteConcern, а потом слить что «мол там еще много проблем», это явно выдает клоуна

Какие, если не секрет и почему? Как полет?

Да.

PostgreSQL (опционально MS SQL Server) для долговременного хранения.

SQLite для временных данных.

SQLite для временных данных.

И оно лучше чем Postgre для это задачи?

В проде oracle, bdb, два проприетарных самописных аналога hadoop'а, один проприетарный самописный key-value.

В тестинге плюс к этому mysql, apache kafka (в некотором роде тоже бд), zookeeper.

Разные данные, разные базы. Полет отличный. Кассандру мы не осилили из-за проблем с восстановлением данных, одного из конкурентов кассандры тоже осилили по тем же самым причинам.

Зачем самописный key-value? И почему Oracle/MySQL в одном проекте?

bdb, тот который обычный, или на Java?

Зачем самописный key-value?

Затем, что другие не устроили по тем или иным причинам.

И почему Oracle/MySQL в одном проекте?

oracle это legacy, уходим с него потихоньку

bdb, тот который обычный, или на Java?

обычный, причем используется с репликацией, транзакциями и прочим фаршем :)

Затем, что другие не устроили по тем или иным причинам.

Если он кардинально другой, будете опенсорсить?

Если он кардинально другой, будете опенсорсить?

Не имеет смысла, hdfs ту же задачу уже решает лучше, поэтому собственный велосипед у нас в статусе legacy и скоро его не будет :)

Да, конечно, использование нескольких БД имеет смысл. Каждый инструмент по своему назначению.

Автор статьи из конкурирующей компании + неосиляторы safe mode, поэтому можно только прислушаться. Выбирайте инструмент по назначению. Монго неплоха для приложений с жирным джаваскриптом, с бэкендом на Node.js. Хороша для хранения сырых неструктурированных данных, аналитики. Для случая когда читаем много, а пишем мало. Когда нельзя чётко выделить агрегаты и нужны джоины, чтобы избегать дублицирования в Монге. Если нужны ACID, ссылочная целостность, нафиг брать Монгу? Берите Postgres - грамотная база, проверена временем, есть дрова, ОРМ для всех мало мальски популярных языков и платформ.

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

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

Хипстерский подход. У меня на проекте тоже самое - выбрали монгу , без вменяемого технического обоснования и всё пихаем туда, хотя для большинства наших данных идеально подходит реляционка. Наши «симптомы» похожи на эту ситуацию - http://www.plotprojects.com/why-we-use-postgresql-and-slick/ Так что смотрите, с ростом проекта ситуация может ухудшиться и будете в конце концов кусать пальцы, как бы мигрировать на более подходящее решение. По поводу изначального вопроса - да, это нормально юзать несколько баз, если они используются так как надо. К примеру, Redis для кэша, Монга для статистики, сырых данных. Успешных примеров много в Интернете, навскидку, в Ruby/Rails популярна связка Postgres + Redis.

Оно локальное и обмен шустрее. Сервер PostgreSQL может быть шибко далеко и туда-сюда гонять временные данные, нужные только конкретному клиенту невыгодно. А плодить сервера на каждом клиенте и синхронизировать их - не вариант для нас.

SqlServer+Oracle+Cassandra

А что такое «ваш проект»?

berkleydb для сиюминутных данных + postgresql/oracle для долгосрочного хранения.

А плодить сервера на каждом клиенте и синхронизировать их

есть пример приложения?

оркаел (легаси) + постгрес

в планах выкинуть оракел и в самописный appent-only журнал вынести большую часть данных постгреса

Нет, это на работе и не опенсорс.

oracle это legacy, уходим с него потихоньку

а почему? какие такие спец.плюшки есть в мс-е?

а почему?

Слишком сложный, плохо масштабируемый, деньги надо ораклу платить ...

какие такие спец.плюшки есть в мс-е?

Никаких нет. Раньше в оракле работало всё, все задачи проекта, сейчас задачи разносятся по разным БД.

используем oracle/mysql/mnesia

Используется.

Есть основная БД, совмещающая key-value и RDBMS, и есть sqlite для модуля ручного ввода данных, если пользователь так и не осилил автоматизацию

Данные в Oracle кешь и сессии в mysql.

В данный момент oracle + kdb + mongodb. Kdb для исторических данных. Монга для всякого шлака.

А что про кассандру очевидно? Репликацию никто не отменял же.

В прошлом комбинировал key-value с базой полнотекстового поиска и с реляционкой. Очень забавная архитектура была (не мной придуманая).

В прошлом комбинировал Redis (первичная обработка толстых потоков данных) с MySQL (основное хранилище в которое редко пишут, но очень часто читают).

Сейчас использую key-value как failover для постгреса. Моя задумка, в этом конкретном случае оправданная.

Мне проще использовать зрелые реляционки, пока серьезных проблем с масштабированием не встречал. key-value считаю хипстерством и юзаю только если без этого совсем никак.

У меня было ситуация, когда заказчик выдал виртуалку для основной БД. Достаточно мощную... для первых двух лет. А потом внезапно зачесалось отчёты строить.

Я взял и запихнул кэш в локальную (в смысле на клиенте) sqlite :)

В данный момент oracle + kdb + mongodb. Kdb для исторических данных. Монга для всякого шлака.

Интересно. Т.е. в этом проекте kdb+ не используется как in-memory db?