|
|
|
| Сейчас есть около 600тыс. записей.
ид-заведения
ид-пользователя * 20 разделов (учетные записи, мед. книжка)
В дальнейшем планируется сильное расширение. До 2млн и выше.
Что здесь лучше использовать, потянет ли Мускул это всё? Какая архитектура должна быть?
База будет стоять на выделенке.
Преимущество должно быть в скорости.
Спасибо. | |
|
|
|
|
|
|
|
для: sl1p
(04.03.2011 в 11:51)
| | >Сейчас есть около 600тыс. записей.
>
>ид-заведения
>ид-пользователя * 20 разделов (учетные записи, мед. книжка)
>
>В дальнейшем планируется сильное расширение. До 2млн и выше.
Это не очень много, вполне рабочие нагрузки, MySQL их вполне потянет.
>Что здесь лучше использовать, потянет ли Мускул это всё?
>База будет стоять на выделенке.
Т.е. вы можете выбирать версию MySQL? Ориентируйтесь тогда на 5.1, в этой версии реализовано сегментирование - слишком объемные таблицы можно будет разбивать на части (по годам или по тысячам).
>Какая архитектура должна быть?
>Преимущество должно быть в скорости.
Очень внимательно следите за индексами - смотрите свои наиболее популярные запросы (на начальном этапе возможно даже по ним стоит вести статистику) и подбирайте под них индексы. Я так понимаю, INSERT и DELETE запросы будут гораздо реже, по сравнению с SELECT-запросами? В этом случае не скупитесь на индекы.
Если совсем препрет, хотя при ваших объемах этого не должно, можно обратиться к репликации, когда вы ставите рядом несколько серверов - один мастер, на него идут все DELETE, UPDATE и INSERT запросы и несколько слейв-серверов, которые реплицируют данные с мастера и на них идут все SELECT-запросы. Однако, я думаю до этого дело не дойдет - это удел социальных сетей, в вашем случае не должно быть такого бешенного обращения к базе данных. | |
|
|
|
|
|
|
|
для: cheops
(04.03.2011 в 12:11)
| | ну да это понятно. Здесь просто нужно перенести всю бумажную инфо пациентов в электронный вид + веб интрефейс для доступа к ним.
Не будет ли тупить база в нахождении инфо определенного юзера среди этой макулатуры? | |
|
|
|
|
|
|
|
для: sl1p
(04.03.2011 в 13:36)
| | Если таблицы будут достаточно нормализированы, т.е. если вы не раздуете таблицу пользователей до нескольких гигибайт и она останется достаточно компактной - все будет искаться достаточно шустро. | |
|
|
|