Основнок время при работе вебсайта это запрос к базе данный. Бак работает жесткий диск: http://pc-information-guide.ru/zhestkij-disk/kak-ustroen-zhestkij-disk-kompyutera-hdd.html Кратко: на общем валу насажено несколько дисков, магнитные дорожки, каждого находятся друг над другом и образуют так называемый цилиндр. Есть коромысло с несколькими магнитными головками, по одной на каждый диск. Коромысло движется, устанавливается на необходимый цилиндр и производит запись/чтение. Движется оно шустро, но конечно это занимает значительное по компьютерным понятиям время. Получается что когда коромыслр установлено на некоторый цилиндр оно может очень быстро считывать или записывать инфлрмацию. А вот если при выполнении sql запроса требуется обращение к таблицам находящимся на разных цилиндрах, то коромыслу приходится перемещаться и время выполнения запроса резко увеличивается, иногда становится неприемлимым. Например для профиля пользователя надо по имеющемуся ключам выбрать наименование страны, региона, города, улицы. Это потребует обращения к таблице с профилем и еще к четырем. Может быть катастрофа, если таблицы находятся на разных цилиндрах. Кеширование помогает но не всегда. Твердотельные диски не имеют этой проблемы. Здесь Вы можете ознакомиться с результатами испытаний и сравненее hdd с ssd https://m.geektimes.ru/post/276052/ Разница в скорости десятки раз А чтобы зло пресечь собрать бы hdd да сжечь! Но hdd память сильно дешевле, без них не обойтись. Так что проблему надо решать, основные методы: - оптимизировать расположение таблиц на диске. Для каждой реально работающей программы есть распределение вероятностей запросов. Можно оптимально расположить таблицы минимизируя среднее время доступа или максимальное время доступа. Это может сделать программист или же программа. Но я такой программы не смог найти. Кто знает подскажите, пожалуйста. - использовать два или больше дисков, также оптимизируя расположение таблиц. Например один из дисков может быть ssd и на нем расположить маленькие таблицы. - использовать оперативную память, она даже быстрее чем sdd, а уж если использовать кеш память то будет совсем быстро. Для этого годятся журналируемые хранилища например redis , memcached. Поскольку большинство сайтов работает на хостингах и виртуальных серверах без сисадмина, было бы полезно сделать журналируемое хранилмще не требующее устпновки, на базе cron. Беда в том что самая популярная субд mysql не позволяет размещать таблицы на разных дисках и тем более не использует журналируемые хранилише. Может быть есть расширения для mysql позволяющие делать это , но я таких найти не сумел. Кто знает подскажите, пожалуйста. Предлагаю основать open source проект и разработать систему для оптимизации дисковой памяти.
Что? Мускул уже не маштабируется? Да и самлинки никто не отменял У тебя большая база? Разметь диск выдели первый раздел под бд. Если дисков два тогда можно два разметить плюс разделы в рейд
конечно mysql маштабируестся. и дело не в размере несколько маленьких таблиц физически расположенных на разных цилиндрах будут читаться очень долго.. я хотел бы увидеть систему доступную для большинства вебмастеров, c минимальной установкой а лучше вообше без нее. 1 in-memory хранилище с поддержкой sql 2 in-memory хранилище не требующее установки на сервер на базе cron 3 расширение для mysql - позволяет размещать таблицы на разных дисках - позволяет размещать таблицы в in-memory хранилище - анализирует эффективность размещения таблиц для данного потока запросов и выдает рекомендации по его оптимизации знаете ли Вы чтото подобное?
@lerneree Ты изобретаешь не нужный велосипед. Никто так не делает. Если на диски большая нагрузка делают рейды. Как поступить в твоем случаи я описал выше. Все это можно решить при помощи базовых знаний linux
еще раз- я хочу сделать систему требующую минимальных знаний и усилий. и она будет востребована. конечно если это расщирение для мускула то установка понадобится. но это совсе\м не трудно. in memory хранилище redis и тп тоже легко устанвливается. а вот in memory хранилище с поддержкой sql и установкой в crone дополнительных знаний не потребует если знаешь чтото по вопросам что я задал помоги. буду благодарен
Нельзя держать базу в оперативке. НЕЛЬЗЯ! Забудь об этом. Не делай так. Держать можно кэш запроса. В redis например
Только для тестов. Только для разработки. Но еще раз не делай так! https://www.sqlite.org/inmemorydb.html
базу в опративке держат и это уже стандарт. есть щанс потерять некотроые данные но на это идут. кроме того нсли маленькие таблицы держать на ssd а большие на hdd будет очень эффективно
У тебя и так таблицы находятся в разных файлах. Никто не мешает перенести таблицу на другой диск и сделать на нее ссылку. --- Добавлено --- Зачем? Если это статические данные ты и так можешь все закэшировать. Если это динамика которая обновляется каждую секунду зачем терять данные? Если в бд нет записи тогда согласен. Но в других случаях точно нет.
про sqllite знаю. это не совесм то что надо. больше всего интересует приложение для мускула. я это реализую. это часть единой системы https://php.ru/forum/threads/doloj-backend-vse-delaem-na-javascript-v-frontend.69847/ https://php.ru/forum/threads/idiomy-programmirovanija.69849/
https://stackoverflow.com/questions/10692398/how-do-i-make-a-mysql-database-run-completely-in-memory Но учти mysql не такая и глупая и все что нужно она и так в оперативке держит + есть my.conf
я знаю про кеш мускула не всегда помогатает. я хочу сделать чтоб вабще все было тупо. я 12 лет жил в сша щас в израиле знаю что там идет. надо разобраться как хорошо сделать. пока оптимальным вижу перехват и перенапрваление ввода вывода мускула. можно сделать очень гибкую систему --- Добавлено --- и в перспективе я хочу использовать исскуственный интелект нейронные сети для анализа сайта. чтоб вебмастер ни о чкм не думал. 95% думать не хотят
и тарантул прям весна в разгаре, охуенные тексты попёрли --- Добавлено --- вот это шедевр: попёрло победа, йопт божжжи а ты знаешь, что это вообще значит? =) всё не так просто. это key-value хранилища, там индексов нет. вот ещё шедевр БЕЗНОГNМ серьёзно? что вообще блин значит это? ладно, мне надоело. --- Добавлено --- тоже кстати копил
на другом форуме мне многое разяснили уговорили не лезть в mysql и не хардкодить. остановилися на том чтобы сделать in memory data base на основе sqllite mongodb redis чтоб там был и sql и json и key value. сейчас очень многие используют mysql с redis или memcashed. imdb с привычным sql может быть удобнее cron это конечно подозрительно. in memory db это демон и требует установки. вроде бы можно повесить скрипт в крон и сделать журналирование тогда не надо ничего на сервер устанавливать. но подводные камни нверняка есть
Не умеешь ты читать между строк. Ладно кину ссылку https://sailsjs.com/documentation/c...apters#?community-supported-database-adapters И не забудь пролистать вверх страницы