| |||||||||
| |||||||||
Добрый день! Подскажите, пожалуйста, когда планируется 7 версия с мускулом? Спасибо.
Думаю на днях. скорее к понедельнику-вторнику.
Что делается или сделано:
-теперь не будет отдельных скриптов(почти) с префиксом mysql, одна единственная админка
-я вшиваю поддержку sql в существующие модули, поэтому все фишки файловой БД будут автоматически становится фишками БД MySQL - это была основная проблема, но я ее решил совмещенным режимом работы (тем более EWC стало настоящей СУБД, только сфинкса не хватает):
-пока EWC будет работать в совмещенном режиме при выборе MySQL в качестве хранения БД товаров (пользователей пока не выбирайте в качестве хранения в MySQL БД) - это означает что все товары вносятся в базу MySQL, в которой хранятся кроме самих товаров, их рейтинги, юнифиды, enum-ы, внешний склад и тому подобная служебка в первых 10 столбцах. с 11 столбца начинаются столбцы те же что и в db_index
-при индексации они расползаются в db_index.txt (общий индекс, который может работать самостоятельно! при крэше MySQL или при дропе ее), далее в преиндексы разделов и фасет товаров (итемы)
-при заходе на страницы, сортировке товаров создается файловый кэш, все как обычно, то есть как такового доступа к БД MySQL нет!
При СП - режиме - ОРГи заполняют только свои файловые БД не имея доступа к БД mySQL
при индексации идет наполнение БД MySQL ОРГ-базами.
Плюсы совмещенного режима:
-всегда есть бекап базы и при креше и дропе можно все восстановить простой миграцией (такой пункт есть в ADM-ДОПОЛНИТЕЛЬНО) или даже сделать автопереключение на режим files (это я подумаю)
-отсутствие SQL уязвимостей
-не надо переделывать все и вся
-БД можно использовать в других местах по вашему усмотрению
-миграция туда и обратно
Минусы совмещенного режима:
-при админской работе приходится править обе БД сразу, что немного замедляет скорость админинья.
-сложно прикрутить сфинкс (нужен при огромном кол-ве товаров под 100000 и выше)
-мемкэшед остается не задействован, но об этом ниже.
Теперь что сделано под совмещенный режим:
-Админ товаров
-Удаление товара
-Убирание товара из продажи и занесение в архив
-Редактирование карточки товара
-При выборе MySQL и windows-1251 кодировки на сайте, автоматически БД переводится в режим запросов cp1251 (не надо настраивать апач)
Что надо сделать:
-Клонирование товара
-Удаление разделов товара
-Заведение нового товара
Неспешно:
-поиск и замена в MySQL базе (и сейчас можно сделать через админку - но только через бекап MySQL Базы в файловую, поиск и замена и миграция обратно)
-вывод товара напрямую из MySQL базы (для использования мемкэша), хотя кто использует файловый кэш - это некритичный пункт
-подбор товара напрямую из MySQL базы, позволит прикруть мемкэшед и сфинкса
Очень неспешно:
-Прикрутить MySQLi
-Универсальный API доступа к БД
-Юникод движка (только при использовании БД MySQL)
Что делается или сделано:
-теперь не будет отдельных скриптов(почти) с префиксом mysql, одна единственная админка
-я вшиваю поддержку sql в существующие модули, поэтому все фишки файловой БД будут автоматически становится фишками БД MySQL - это была основная проблема, но я ее решил совмещенным режимом работы (тем более EWC стало настоящей СУБД, только сфинкса не хватает):
-пока EWC будет работать в совмещенном режиме при выборе MySQL в качестве хранения БД товаров (пользователей пока не выбирайте в качестве хранения в MySQL БД) - это означает что все товары вносятся в базу MySQL, в которой хранятся кроме самих товаров, их рейтинги, юнифиды, enum-ы, внешний склад и тому подобная служебка в первых 10 столбцах. с 11 столбца начинаются столбцы те же что и в db_index
-при индексации они расползаются в db_index.txt (общий индекс, который может работать самостоятельно! при крэше MySQL или при дропе ее), далее в преиндексы разделов и фасет товаров (итемы)
-при заходе на страницы, сортировке товаров создается файловый кэш, все как обычно, то есть как такового доступа к БД MySQL нет!
При СП - режиме - ОРГи заполняют только свои файловые БД не имея доступа к БД mySQL
при индексации идет наполнение БД MySQL ОРГ-базами.
Плюсы совмещенного режима:
-всегда есть бекап базы и при креше и дропе можно все восстановить простой миграцией (такой пункт есть в ADM-ДОПОЛНИТЕЛЬНО) или даже сделать автопереключение на режим files (это я подумаю)
-отсутствие SQL уязвимостей
-не надо переделывать все и вся
-БД можно использовать в других местах по вашему усмотрению
-миграция туда и обратно
Минусы совмещенного режима:
-при админской работе приходится править обе БД сразу, что немного замедляет скорость админинья.
-сложно прикрутить сфинкс (нужен при огромном кол-ве товаров под 100000 и выше)
-мемкэшед остается не задействован, но об этом ниже.
Теперь что сделано под совмещенный режим:
-Админ товаров
-Удаление товара
-Убирание товара из продажи и занесение в архив
-Редактирование карточки товара
-При выборе MySQL и windows-1251 кодировки на сайте, автоматически БД переводится в режим запросов cp1251 (не надо настраивать апач)
Что надо сделать:
-Клонирование товара
-Удаление разделов товара
-Заведение нового товара
Неспешно:
-поиск и замена в MySQL базе (и сейчас можно сделать через админку - но только через бекап MySQL Базы в файловую, поиск и замена и миграция обратно)
-вывод товара напрямую из MySQL базы (для использования мемкэша), хотя кто использует файловый кэш - это некритичный пункт
-подбор товара напрямую из MySQL базы, позволит прикруть мемкэшед и сфинкса
Очень неспешно:
-Прикрутить MySQLi
-Универсальный API доступа к БД
-Юникод движка (только при использовании БД MySQL)
самое главное теперь на фоне внедрения мускула все не сломать=))
MySQL внедряется пока в "теневом" режиме, имеет доступ к MySQL базе на запись и чтение - пока только администратор.
Поэтому ничего не поломается.
Юзеры как получали индексы и кеш, так и будут. Потом посмотрим, возможно и вывод товаров сделаю, но пока нет смысла.
MySQL внедряю исключительно под Sphinx ибо своими силами неохота его заново создавать. Дело в том что при количестве товаров свыше 100K поиск с подсказками начинает подтормаживать. Да и подбор товара только в своей категории - бесит. Хочу чтобы подбор товара был во всей базе и был мгновенный.
Я бы мог создать фасетные файловые индексы при индексации... но, увеличение времени индексации - не очень то хотелось бы, фасеты - их надо будет периодически чистить, создавать либо крон-задания, либо демон... А так есть готовый Сфинкс - хороший проверенный модуль, вот пусть он и обрабатывает БД и создает фасеты.
Поэтому ничего не поломается.
Юзеры как получали индексы и кеш, так и будут. Потом посмотрим, возможно и вывод товаров сделаю, но пока нет смысла.
MySQL внедряю исключительно под Sphinx ибо своими силами неохота его заново создавать. Дело в том что при количестве товаров свыше 100K поиск с подсказками начинает подтормаживать. Да и подбор товара только в своей категории - бесит. Хочу чтобы подбор товара был во всей базе и был мгновенный.
Я бы мог создать фасетные файловые индексы при индексации... но, увеличение времени индексации - не очень то хотелось бы, фасеты - их надо будет периодически чистить, создавать либо крон-задания, либо демон... А так есть готовый Сфинкс - хороший проверенный модуль, вот пусть он и обрабатывает БД и создает фасеты.
Под MySQL:
Сделано клонирование строки
Товар дня
Допилено понимание MySQL-ем custom_cart.inc и сс_xxxx_.inc
допилена миграция в MySQL с учетом custom_cart и сс-шек (custom столбцы названы теперь col_XXX)
Допилены основные параметры
Сделано клонирование строки
Товар дня
Допилено понимание MySQL-ем custom_cart.inc и сс_xxxx_.inc
допилена миграция в MySQL с учетом custom_cart и сс-шек (custom столбцы названы теперь col_XXX)
Допилены основные параметры
