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

Тема в разделе "Базы данных", создана пользователем romas_s, 22 ноя 2017.

Модераторы: latteo
  1. romas_s

    romas_s

    Регистр.:
    9 ноя 2012
    Сообщения:
    245
    Симпатии:
    69
    Всем привет.
    Выделенный сервер имеется.

    Нужна 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
     
    Последнее редактирование: 24 ноя 2017
  2. Nei

    Nei Nosce te ipsum

    Регистр.:
    5 сен 2009
    Сообщения:
    648
    Симпатии:
    513
    2 000 0000 записей для MySQL это не особо много. Если норм сервер и использовать кеширование, то вполне без всяких разбиений таблиц будет работать нормально.
     
  3. artemka9p

    artemka9p Создатель

    Регистр.:
    15 окт 2017
    Сообщения:
    15
    Симпатии:
    4
    согласен на норм железа с правильным индексом поиск по 2кк записей пройдет мгновенно
     
  4. romas_s

    romas_s

    Регистр.:
    9 ноя 2012
    Сообщения:
    245
    Симпатии:
    69
    CPU Intel Xeon E5-2697 v2 - 12 ядер
    ОЗУ 32гб DDR3
    SSD на 1тб.
    lan гигабитный на все направления.

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

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

    latteo Эффективное использование PHP, MySQL

    Moderator
    Регистр.:
    28 фев 2008
    Сообщения:
    1.582
    Симпатии:
    1.484
    Почти любая CMS - это в первую очередь универсальность. И за неё надо платить и чаще всего понижением производительности.
    С другой стороны, судя по вопросу, шансы допустить косяки при проектировании, которые повесят всю систему гораздо сильнее чем выбор самой тормознутой CMS отнюдь не нулевые ;)

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

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

    alex_me

    Регистр.:
    25 янв 2017
    Сообщения:
    162
    Симпатии:
    110
    Кешируется ответ сервера, то есть, например вывод каждой страницы с запчастью, т.е. запрос к базе не выполняется.
    Обращение к базе соответственно имеет значение в основном в форме поиска.
    вин же индексируется
    есть также внешние индексаторы для больших объемов, если нужно, чтобы глобальный поиск по миллионам записей летал
    https://www.algolia.com/
     
  7. romas_s

    romas_s

    Регистр.:
    9 ноя 2012
    Сообщения:
    245
    Симпатии:
    69
    • хранилище данных в виде пар "ключ-значение" — MySQL;
    Может кто то навести пример, не могу понять что значит хранение данных ключ-значении, данных то много разных и таблиц тоже.
     
  8. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    ключ-значение - это обычная логика кеширующих механизмов. Если сравнить с каталогом библиотеки, то ключ - карточка книги, а значение - сама книга.

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

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

    Я сейчас пытаюсь переделать одну тормозную, но милую сердцу CMS интернет-магазина.
    https://www.nulled.cc/threads/291347/page-12#post-2769326

    Самые долгие операции получаются, в тех местах, где надо получать данные наоборот. Т.е. когда надо не 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 нравится это.
  9. romas_s

    romas_s

    Регистр.:
    9 ноя 2012
    Сообщения:
    245
    Симпатии:
    69
    а разве можно 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);
     
    Последнее редактирование: 24 ноя 2017
  10. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    244
    Симпатии:
    87
    $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;
     
    romas_s нравится это.