Архитектура базы и приложения

[ruFog]

Здравствуйте!

Я разработал небольшой сайт с базой данных товаров города. Изначально сайт был адаптирован под местного покупателя - все данные о товарах и учетные записи зарегистрированных пользователей хранятся в одной базе данных. Количество одновременно существующих в базе данных товаров ~15000 для нашего города. Причем сайт позволяет очень гибко фильтровать и сортировать товары и эти операции составляют моё конкурентное преимущество. Но есть и обратная сторона медали - такие запросы с одновременной сортировкой и фильтрацией по нескольким критериям достаточно "тяжелы" для MySQL (я на данный момент не использую кеширование). В настоящий момент наша команда намерена развивать этот проект в соседних городах. Я бы хотел реализовать гибкую масштабируемую базу данных, но не имею представления как это сделать лучше.

Возможно лучше будет сделать для каждого города отдельную базу данных + иметь некое отдельное хранилище пользователей (один раз зарегистрировавшись пользователь может размещать объявления о товарах в разных городах, т.е. в разных базах данных).

Как придуманную мной модель реализовать на практике представляю себе слабо. Может быть не стоит вобще заморачиваться, если число записей не будет превышать полумилиона, а просто грамотно прикрутить кеширование? Хотелось бы услышать совета профессионала. Самому не доводилось работать с крупными проектами. Заранее благодарен.

PS: вот штатный запрос в mysql для:

SELECT * FROM `ndvbase` WHERE ndvbase.CITY=:p1 AND ndvbase.TYPE=:p2 AND ndvbase.ONLYFORUSERS=:p3 AND ndvbase.POSITION_DISTRICT IN (:p4) AND ndvbase.NUM_OF_ROOM IN (:p5) AND ndvbase.STATE IN (:p6,:p7) AND ndvbase.PRICE>=:p8 ORDER BY ndvbase.CREATED_AT DESC,ndvbase.RANK DESC LIMIT 840, 20

MYSQL5.1

[squirL]

Сообщение от ruFog Здравствуйте! Но есть и обратная сторона медали - такие запросы с одновременной сортировкой и фильтрацией по нескольким критериям достаточно "тяжелы" для MySQL (я на данный момент не использую кеширование).

индексы вы, надеюсь, используете?

Сообщение от ruFog Возможно лучше будет сделать для каждого города отдельную базу данных + иметь некое отдельное хранилище пользователей (один раз зарегистрировавшись пользователь может размещать объявления о товарах в разных городах, т.е. в разных базах данных).

а смысл в отдельной базе? для пользователей - нужна просто отдельная таблица и все.

Сообщение от ruFog PS: вот штатный запрос в mysql для: SELECT * FROM `ndvbase` WHERE ndvbase.CITY=:p1 AND ndvbase.TYPE=:p2 AND ndvbase.ONLYFORUSERS=:p3 AND ndvbase.POSITION_DISTRICT IN (:p4) AND ndvbase.NUM_OF_ROOM IN (:p5) AND ndvbase.STATE IN (:p6,:p7) AND ndvbase.PRICE>=:p8 ORDER BY ndvbase.CREATED_AT DESC,ndvbase.RANK DESC LIMIT 840, 20 MYSQL5.1

explain для этого запроса штатного покажите.

[ruFog]

Вот Explain:

id = 1
select_type = SIMPLE
table = ndvbase
type = index_merge
possible_keys = ndvbase_I_1,ndvbase_I_3,ndvbase_I_5,ndvbase_I_13,n dvbase_I_15,ndvbase_FI_2
key = ndvbase_I_5,ndvbase_I_1,ndvbase_FI_2,ndvbase_I_3
key_len = 2,4,4,5
ref = NULL
rows = 1548
Extra = Using intersect(ndvbase_I_5,ndvbase_I_1,ndvbase_FI_2,ndv base_I_3); Using where; Using filesort

Предлагаете все оставить в одной базе данных? А как расширяться в случае высокой нагрузки на БД? Master-slave?

[squirL]

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

[ruFog]

Для большого набора городов таблицы идентичны. Можно оставить все в одной БД, но как mysql будет справляться с запросами (наподобии вышеприведенного), если в базе будет порядка полумиллиона записей? Мне к сожелению не доводилось сталкиваться с архитектурами "крутых" проектов. Может быть они тоже все в одной базе держат и просто докупают слейв-серверов для распределения нагрузки..

PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.

[kot_]

Сообщение от ruFog Для большого набора городов таблицы идентичны. Можно оставить все в одной БД, но как mysql будет справляться с запросами (наподобии вышеприведенного), если в базе будет порядка полумиллиона записей? Мне к сожелению не доводилось сталкиваться с архитектурами "крутых" проектов. Может быть они тоже все в одной базе держат и просто докупают слейв-серверов для распределения нагрузки.. PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.

Вроде бы у Велингтона данным вопросам уделялось некоторое внимание. Но вообще то база на полмиллиона записей - само по себе это не слишком много на сегодняшний момент. Я кстати недавно описывал решение в которой используется одна база для нескольких сайтов (с несколькими общими таблицами) - в принципе тот же подход можно использовать и для обратной ситуации - один сайт на несколько баз - разницы нет никакой.