помогите со структурой БД CMS

[romas_s]

Всем привет.
Выделенный сервер имеется.

Нужна CMS для новостного сайта с 200 000 + материалов с онлайном 300 - 500 человек.

Так же нужна CMS для интернет магазина с 2 000 000 товарами.

Я так понимаю что готовые CMS использовать тут не варик.

Подскажите по поводу формирования структуры базы данных, правильно ли я рассуждаю:
1. под каждую категорию товаров - своя таблица, таблицы с меньшим количеством строк должны быстрее считываться с базы, нежели 1 таблица на 2 лямами записей.
2. фильтр поиска товаров в пределах выбранной категории, исходя с пункта 1, будет перебиваться только записи текущей категории.
3. фильтр поиска для всего магазина - как реализовать хз. приходит на ум только полный перебор всех таблиц. Как реальный пример - поиск по WIN коду запчасти.
4. поиск по сайту - создается отдельная база данных в которой будут храниться ключи товаров с основной базы для ускорения поиска, либо думаю использовать google поиск.

Отличный мануал по запросах SQL
dklab.ru/lib/DbSimple/manual.html

 

[Nei]

2 000 0000 записей для MySQL это не особо много. Если норм сервер и использовать кеширование, то вполне без всяких разбиений таблиц будет работать нормально.

 

[artemka9p]

согласен на норм железа с правильным индексом поиск по 2кк записей пройдет мгновенно

 

[romas_s]

CPU Intel Xeon E5-2697 v2 - 12 ядер
ОЗУ 32гб DDR3
SSD на 1тб.
lan гигабитный на все направления.

Какое может быть кеширование с поиском по WIN коду??? каждый товар имеет свой уникальный идентификатор.
Вероятность поиска по одному и тому же WIN коду просто ничтожно мала.

с генерированием CSS и HTML нет проблем, вся загвоздка в скорости выборки данных с базы данных.
Все остальное мало интересует.

 

[latteo]

Нужна CMS для новостного сайта с 200 000 + материалов с онлайном 300 - 500 человек.
Так же нужна CMS для интернет магазина с 2 000 000 товарами.
Я так понимаю что готовые CMS использовать тут не варик.

Почти любая CMS - это в первую очередь универсальность. И за неё надо платить и чаще всего понижением производительности.
С другой стороны, судя по вопросу, шансы допустить косяки при проектировании, которые повесят всю систему гораздо сильнее чем выбор самой тормознутой CMS отнюдь не нулевые

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

Определённая логика здесь есть, но правильно расставленные индексы и разумное наплевательство на нормализацию говорит о том, что не зачем так заморачиваться и в одной таблице будет работать так же быстро как и в десятке.
А вот добавление новой категории и поиск по всем записям добавят головной боли.

3. фильтр поиска для всего магазина - как реализовать хз. приходит на ум только полный перебор всех таблиц. Как реальный пример - поиск по WIN коду запчасти.

Вот тут как раз таки и получаем выигрыш от 1 таблицы, индекс по полю WIN позволит провести поиск за десятки мс даже при 5-10кк записей.

 

[alex_me]

Какое может быть кеширование с поиском по WIN коду???

Кешируется ответ сервера, то есть, например вывод каждой страницы с запчастью, т.е. запрос к базе не выполняется.
Обращение к базе соответственно имеет значение в основном в форме поиска.
вин же индексируется
есть также внешние индексаторы для больших объемов, если нужно, чтобы глобальный поиск по миллионам записей летал
Для просмотра ссылки Войди или Зарегистрируйся

 

[romas_s]

Фейсбук - MySQL Для просмотра ссылки Войди или Зарегистрируйся по моим прикидкам порядка 2-3 пб инфы в базе

• хранилище данных в виде пар "ключ-значение" — MySQL;

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

 

[babahalki]

• хранилище данных в виде пар "ключ-значение" — MySQL;

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

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

Такой же по принципу механизм я приделал себе.

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

Я сейчас пытаюсь переделать одну тормозную, но милую сердцу CMS интернет-магазина.
Для просмотра ссылки Войди или Зарегистрируйся

Самые долгие операции получаются, в тех местах, где надо получать данные наоборот. Т.е. когда надо не 1-2 записи вытащить из таблицы на 2млн. строк, а когда надо 200 тыс. записей сначала взять из этой таблицы, результат использовать как фильтр для выборки в другой таблице. Или еще круче, результат выборки будет где-то 10 строк - названий фирм. Но нужны только такие, которые относятся к товарам, которые в наличии, т.е. остаток > 0, у которых не отключена видимость и которые входят в набор категорий из примерно 150 значений.


Вот такой запрос у меня примерно 5 секунд выполняется, если вообще без кеша - это очень долго. Сейчас пытаюсь его оптимизировать его.

SELECT b.id, b.name, b.url, b.meta_title, b.meta_keywords, b.meta_description, b.description, b.image FROM s_brands b WHERE 1 AND b.id in (SELECT brand_id FROM s_products p WHERE 1 AND p.visible=1 AND p.id in (SELECT product_id FROM s_products_categories WHERE category_id in ('7','95','128','207','6','271','311','342','37','71','137','216','227','70','83','109','135','143','278','363','82','88','383','87','94','98','232','299','380','5','18','96','360','17','28','31','45','65','97','110','121','129','145','149','154','206','220','224','228','250','259','260','269','290','315','361','27','49','62','382','172','174','237','251','274','327','330','284','300','48','118','202','215','254','303','359','381','117','171','175','286','379','170','245','291','293','244','4') ))

 

[romas_s]

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

Такой же по принципу механизм я приделал себе.

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

Я сейчас пытаюсь переделать одну тормозную, но милую сердцу CMS интернет-магазина.
Для просмотра ссылки Войди или Зарегистрируйся

Самые долгие операции получаются, в тех местах, где надо получать данные наоборот. Т.е. когда надо не 1-2 записи вытащить из таблицы на 2млн. строк, а когда надо 200 тыс. записей сначала взять из этой таблицы, результат использовать как фильтр для выборки в другой таблице. Или еще круче, результат выборки будет где-то 10 строк - названий фирм. Но нужны только такие, которые относятся к товарам, которые в наличии, т.е. остаток > 0, у которых не отключена видимость и которые входят в набор категорий из примерно 150 значений.


Вот такой запрос у меня примерно 5 секунд выполняется, если вообще без кеша - это очень долго. Сейчас пытаюсь его оптимизировать его.

SELECT b.id, b.name, b.url, b.meta_title, b.meta_keywords, b.meta_description, b.description, b.image FROM s_brands b WHERE 1 AND b.id in (SELECT brand_id FROM s_products p WHERE 1 AND p.visible=1 AND p.id in (SELECT product_id FROM s_products_categories WHERE category_id in ('7','95','128','207','6','271','311','342','37','71','137','216','227','70','83','109','135','143','278','363','82','88','383','87','94','98','232','299','380','5','18','96','360','17','28','31','45','65','97','110','121','129','145','149','154','206','220','224','228','250','259','260','269','290','315','361','27','49','62','382','172','174','237','251','274','327','330','284','300','48','118','202','215','254','303','359','381','117','171','175','286','379','170','245','291','293','244','4') ))

а разве можно select в select вставлять??

может подскажите как выполнить 1 запрос на добавление 1000 новых записей в базу данных??

А то через цикл банальное создание 1000 записей с 2 числовыми полями приводит к ооооооочень долгому ожиданию около 30 сек.

Спойлер: код

    $mysql_db_host =     'localhost';         // сервер
    $mysql_db_user =     'info_za500_test';     // пользователь
    $mysql_db_user2 =     'info_za500_test2'; // пользователь2
    $mysql_db_pass =    '';          // пароль
    $mysql_db_name =     'info_za500_test';     // имя базы данных

$new_line = 1000;
$max_line = 7000;
function new_line_namber ($mysqli, $mysql_db_name, $table_name, $new_line, $max_line)
{ 
    for ($i = 1; $i <= $new_line; $i ++)
    {
        $result_set = $mysqli->query("SELECT * FROM `$table_name`");
        //$namber = $result_set->num_rows + 1;
        $namber = mt_rand(-10,10);
     
        if ($result_set->num_rows >= $max_line) return;
     
        $mysqli->query ("INSERT INTO `$mysql_db_name`.`$table_name` (`id`, `namber`) VALUES (NULL, " . "$namber" . ");");
    }

}
new_line_namber  ($mysqli, $mysql_db_name, $table_name, $new_line, $max_line);

 

[babahalki]

а разве можно select в select вставлять??

может подскажите как выполнить 1 запрос на добавление 1000 новых записей в базу данных??

А то через цикл банальное создание 1000 записей с 2 числовыми полями приводит к ооооооочень долгому ожиданию около 30 сек.

Спойлер: код

    $mysql_db_host =     'localhost';         // сервер
    $mysql_db_user =     'info_za500_test';     // пользователь
    $mysql_db_user2 =     'info_za500_test2'; // пользователь2
    $mysql_db_pass =    '';          // пароль
    $mysql_db_name =     'info_za500_test';     // имя базы данных

$new_line = 1000;
$max_line = 7000;
function new_line_namber ($mysqli, $mysql_db_name, $table_name, $new_line, $max_line)
{
    for ($i = 1; $i <= $new_line; $i ++)
    {
        $result_set = $mysqli->query("SELECT * FROM `$table_name`");
        //$namber = $result_set->num_rows + 1;
        $namber = mt_rand(-10,10);
    
        if ($result_set->num_rows >= $max_line) return;
    
        $mysqli->query ("INSERT INTO `$mysql_db_name`.`$table_name` (`id`, `namber`) VALUES (NULL, " . "$namber" . ");");
    }

}
new_line_namber  ($mysqli, $mysql_db_name, $table_name, $new_line, $max_line);

$vals = array();
for ($i = 1; $i <= $new_line; $i ++)
{
$vals[] = "( NULL, " . mt_rand(-10,10) . ")";
}
$vals = implode(", " $vals);

$mysqli->query ("INSERT INTO `$mysql_db_name`.`$table_name` (`id`, `namber`) VALUES $vals;