Архитектура базы и приложения
Здравствуйте!
Я разработал небольшой сайт с базой данных товаров города. Изначально сайт был адаптирован под местного покупателя - все данные о товарах и учетные записи зарегистрированных пользователей хранятся в одной базе данных. Количество одновременно существующих в базе данных товаров ~15000 для нашего города. Причем сайт позволяет очень гибко фильтровать и сортировать товары и эти операции составляют моё конкурентное преимущество. Но есть и обратная сторона медали - такие запросы с одновременной сортировкой и фильтрацией по нескольким критериям достаточно "тяжелы" для MySQL (я на данный момент не использую кеширование). В настоящий момент наша команда намерена развивать этот проект в соседних городах. Я бы хотел реализовать гибкую масштабируемую базу данных, но не имею представления как это сделать лучше.
Возможно лучше будет сделать для каждого города отдельную базу данных + иметь некое отдельное хранилище пользователей (один раз зарегистрировавшись пользователь может размещать объявления о товарах в разных городах, т.е. в разных базах данных).
Как придуманную мной модель реализовать на практике представляю себе слабо. Может быть не стоит вобще заморачиваться, если число записей не будет превышать полумилиона, а просто грамотно прикрутить кеширование? Хотелось бы услышать совета профессионала. Самому не доводилось работать с крупными проектами. Заранее благодарен.
PS: вот штатный запрос в mysql для:
MYSQL5.1
Я разработал небольшой сайт с базой данных товаров города. Изначально сайт был адаптирован под местного покупателя - все данные о товарах и учетные записи зарегистрированных пользователей хранятся в одной базе данных. Количество одновременно существующих в базе данных товаров ~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
Цитата: ruFog
Здравствуйте!
Но есть и обратная сторона медали - такие запросы с одновременной сортировкой и фильтрацией по нескольким критериям достаточно "тяжелы" для MySQL (я на данный момент не использую кеширование).
Но есть и обратная сторона медали - такие запросы с одновременной сортировкой и фильтрацией по нескольким критериям достаточно "тяжелы" для 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 для этого запроса штатного покажите.
Вот 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,ndvbase_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,ndvbase_I_3); Using where; Using filesort
Предлагаете все оставить в одной базе данных? А как расширяться в случае высокой нагрузки на БД? Master-slave?
id = 1
select_type = SIMPLE
table = ndvbase
type = index_merge
possible_keys = ndvbase_I_1,ndvbase_I_3,ndvbase_I_5,ndvbase_I_13,ndvbase_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,ndvbase_I_3); Using where; Using filesort
Предлагаете все оставить в одной базе данных? А как расширяться в случае высокой нагрузки на БД? Master-slave?
вопрос в том, какова задача. если для разных городов таблицы никак не связаны - да, можно делать отдельную базу. если связи существуют - надо удумать другое решение.
Для большого набора городов таблицы идентичны. Можно оставить все в одной БД, но как mysql будет справляться с запросами (наподобии вышеприведенного), если в базе будет порядка полумиллиона записей? Мне к сожелению не доводилось сталкиваться с архитектурами "крутых" проектов. Может быть они тоже все в одной базе держат и просто докупают слейв-серверов для распределения нагрузки..
PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.
PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.
Цитата: ruFog
Для большого набора городов таблицы идентичны. Можно оставить все в одной БД, но как mysql будет справляться с запросами (наподобии вышеприведенного), если в базе будет порядка полумиллиона записей? Мне к сожелению не доводилось сталкиваться с архитектурами "крутых" проектов. Может быть они тоже все в одной базе держат и просто докупают слейв-серверов для распределения нагрузки..
PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.
PS: где бы вобще почитать про это все дело.. в рунете скудно как-то.
Вроде бы у Велингтона данным вопросам уделялось некоторое внимание. Но вообще то база на полмиллиона записей - само по себе это не слишком много на сегодняшний момент. Я кстати недавно описывал решение в которой используется одна база для нескольких сайтов (с несколькими общими таблицами) - в принципе тот же подход можно использовать и для обратной ситуации - один сайт на несколько баз - разницы нет никакой.