Выбор СУБД под большой проект [закрыт]

#база_данных

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Какую лучше СУБД выбрать под разработку большого проекта?
Mongo DB с ее автоматическим привлекающим внимание тысяч программистов, как пчел
на мед, шардингом и вообще современными возможностями?
MySQL и аналоги ..?
SQLite3? Но у нее есть лимиты памяти баз данных и шардинг никакого смысла в увеличении
скорости не придаст.    

Ответы

Ответ 1

Для начала нужно определиться с каким типом БД вы будете работать. По собственному
опыту могу сказать, что нельзя ответить на вопрос "что лучше: монго или sql". Нужно
исходить из поставленной задачи. 
Документо-ориентированные БД (mongo, couch) будет лучше если в системе вам часто
приходится копировать записи с их зависимостями. Или, например, если не все записи
имеют одинаковые поля.
Если же вам приходится обрабатывать массивы данных для подсчёта неких статистических
данных (например, среднее состояние кассы всех компаний за N-ый период), то здесь к
месту реляционный подход (mysql, postgresql).
Поэтому, чтобы сузить круг выбора БД, для начала выберите её тип исходя из поставленной
вам задачи.


Ответ 2

Есть большая тройка: Oracle, MS SQL Server и IBM DB2. Все остальное это детские шалости,
ну разве что MySQL и Postgres близки к этим гигантам.
Когда вы говорите большой проект, то видимо речь идет не столько о том, что много
данных, но видимо и о том, что много серверов, много коннектов. По человечески умеют
делать кластеризацию только указанные монстры, а всякая мелочь вроде MongoDB и проч.
- не смешите. Ну запихнете вы туда 100 гигов (и то сомневаюсь), а дальше то что? Ну
про SQLite вообще умолчу: ключевое слово здесь lite - то есть легкий, маленький. Хорошо,
хоть не упомянули про Hypersonic SQL :)
Когда проект большой на первый план выходит не столько способность вмещать данные,
столько возможность "держать" нагрузку, использование фич специализированных серверных
процессоров, возможность кластеризации, бэкапа, репликации данных между инстансами.
Ну и не забываем про поддержку. Какую вы поддержку получите с MongoDB и тем паче с
SQLite? Форум полусумасшедших разработчиков-индусов?
В общем смотрите в сторону большой тройки. Я лично, предпочитаю Oracle.
P.S. Почитав про цели:

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

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


Ответ 3

Mysqli или PDO, смотря какая связка.
В данный момент для большого проекта, я выбрал MySQLi + PHP + Jquery + Memcache


Ответ 4

@qsad, что значит (количественные характеристики) большой проект?.
Во многих больших проектах (кластеры из несколько серверов   и систем хранения в
SAN, терабайты дискового пространства) используют Oracle, DB2 или MS-SQL.
Кое с какими данными на эту тему можно ознакомится здесь


Ответ 5

Никакого MySQL. Юзайте постгрес!)


Ответ 6

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


Ответ 7

Холивары вокруг того какая СУБД самая-самая — весьма популярный в интернете вид спорта.
Большинство ответов тут, увы, именно про это. Дабы не повышать напряжённость постараюсь
вовсе не упоминать тут названия различных СУБД.
@qsad, наблюдение за подобными холиварами едва-ли поможет вам разобраться в вопросе,
скорее наоборот запутает. Так-же не стоит рассчитывать услышать тут правильный ответ
на ваш вопрос. Дело в том что сделать правильный выбор тут можно только зная в подробностях
что должна делать система, имея представление об имеющихся ресурсах (людских и материальных).
И самое главное: разбираясь в предметной области. К сожалению вынужден констатировать
что, судя по вашему вопросу, ваших знаний недостаточно для того что-бы задаваться правильными
вопросами (а это наверное самое главное).
Если у вас есть время, мозги, желание и готовность долго изучать что-то не связанное
напрямую с решением конкретной задачи — изучите получше эту тему. Базы данных и проектирование
восоконагруженных и высокодоступных систем это вообще интересно.
Если «проект нужно сдавать уже вчера», или сама тема вам не интересна — наймите опытного
DBA (Database administrator). Хоть я и не представляю как вы отличите адекватного DBA
от чёрт-знает кого.
P.S. должен заметить что у меня есть некоторые соображения о том как-бы могла выглядеть
подобная система. Но я не стану их озвучивать, учитывая что: во-первых мои соображения
основываются на представлении о целевой системе сложившемся из обрывков информации
предоставленных @qsad и гадании на кофейной гуще, во-вторых моего опыта и познаний
очевидно недостаточно что-бы проектировать такие системы.


Ответ 8

Работаю с БД размером ~70 Гб, строк больше 300 млн., и это MySQL!
Проблем нет!