Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: как "содержать" очень много записей?
 
 автор: sl1p   (04.03.2011 в 11:51)   письмо автору
 
 

Сейчас есть около 600тыс. записей.


ид-заведения
ид-пользователя * 20 разделов (учетные записи, мед. книжка)

В дальнейшем планируется сильное расширение. До 2млн и выше.


Что здесь лучше использовать, потянет ли Мускул это всё? Какая архитектура должна быть?

База будет стоять на выделенке.

Преимущество должно быть в скорости.


Спасибо.

  Ответить  
 
 автор: cheops   (04.03.2011 в 12:11)   письмо автору
 
   для: sl1p   (04.03.2011 в 11:51)
 

>Сейчас есть около 600тыс. записей.
>
>ид-заведения
>ид-пользователя * 20 разделов (учетные записи, мед. книжка)
>
>В дальнейшем планируется сильное расширение. До 2млн и выше.
Это не очень много, вполне рабочие нагрузки, MySQL их вполне потянет.

>Что здесь лучше использовать, потянет ли Мускул это всё?
>База будет стоять на выделенке.
Т.е. вы можете выбирать версию MySQL? Ориентируйтесь тогда на 5.1, в этой версии реализовано сегментирование - слишком объемные таблицы можно будет разбивать на части (по годам или по тысячам).

>Какая архитектура должна быть?
>Преимущество должно быть в скорости.
Очень внимательно следите за индексами - смотрите свои наиболее популярные запросы (на начальном этапе возможно даже по ним стоит вести статистику) и подбирайте под них индексы. Я так понимаю, INSERT и DELETE запросы будут гораздо реже, по сравнению с SELECT-запросами? В этом случае не скупитесь на индекы.

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

  Ответить  
 
 автор: sl1p   (04.03.2011 в 13:36)   письмо автору
 
   для: cheops   (04.03.2011 в 12:11)
 

ну да это понятно. Здесь просто нужно перенести всю бумажную инфо пациентов в электронный вид + веб интрефейс для доступа к ним.

Не будет ли тупить база в нахождении инфо определенного юзера среди этой макулатуры?

  Ответить  
 
 автор: cheops   (04.03.2011 в 13:40)   письмо автору
 
   для: sl1p   (04.03.2011 в 13:36)
 

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

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования