- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Планируется работа с огромным количеством данных (от миллиона строк в таблице). Выборка строк планируется по трём параметрам (столбцам). Интересуют советы что лучше выбрать, т.к. важно быстродействие. Так же интересует аргументация и информация об обслуживании БД с таким кол-вом информации.
MySQL достаточно неплохо справляется с таким=)
Грамотно проставленные индексы+InnoDB+транзакции решают!=)
По мне так, если просто хотите хранилище - то мускл, если хотите умную базу - с хранимымы процедурами, таблеспейчсами, и т.д. - то постгрес.
Ну опять же я и то испрользовал и то, но последнее время мне постгресс все больше и больше нравтиься - чего стоит один только морфологичесикй разбор на лету - уууух классная весч.
Зависит от того какое соотношение операций на чтение - запись планируется. Размер здесь не так важен, важен характер операций. Если у вас 95% операций будут простые селекты по трем столбцам, то не факт что вы заметите разницу между постгрёй и мусклом.
Зависит от программера, если он в простгресе как топор в плавании то уж лучше мускул
Зависит от того какое соотношение операций на чтение - запись планируется. Размер здесь не так важен, важен характер операций. Если у вас 95% операций будут простые селекты по трем столбцам, то не факт что вы заметите разницу между постгрёй и мусклом.
+1 воистину
AlienZzzz добавил 12.02.2009 в 16:29
Зависит от программера, если он в простгресе как топор в плавании то уж лучше мускул
Плохо дело коллега, если он и там и там топор ( тогда тут клиника.
neolord, ориентация в основном на запись данных. Но выборка тоже имеет место быть
Зингельшухер, программер одинаково хорошо знаком с обеими бд, но не имел дело с большим кол-вом данных.
FeoOne, дайте задание другому программеру, раз он не может выбрать и обосновать.
На запись - опять же надо смотреть.
MySQL таблицы на движке InnoDB поддерживают транзакции и блокировка построчная - что при одновременном множественном доступе составляет достойную конкуренцию постгре.
Но если речь идет о некоторых сложных операциях записи, глубокой системе разделения групп пользователей, то триггеры, функции и прочие вкусности постгреса очень помогают. Другой вопрос, насколько "одинаково хорошо" знаком ваш прогер с этими вкусностями. Если опыта работы с чисто постгрессовскими штучками у него нет, то скорее всего он все её преимущества запорет. А объем данных в данном случае опять же не сильно важен. А количество одновременных подключений - значимо. Yahoo вон на постгрессе довольно шустро работает.
У меня вот последнее время такой же вопрос возникает. Точнее, появляется уверенность, что нужно учить postgres глядя на то, как из Sun бегут один за другим разработчики Mysql.