Я так понимаю если мне нужно 200Gb, то писать "200G" ? И правильно понимаю, что для VM будет написана та цифра, которую я укажу. Но место ограничена размерами диска где лежит образ. Т.е мне никаких манипуляций больше не надо делать, если я на винте с 500гб свободного,- расширяю образ со 100 до 200гб?
Александр: Не надо утрировать. Все что вы пишите бред. Речь идет не о масштабировании базы с с таблицами где прибавка по 100к в час идет с плюсом каждый день, а о прибавках пользователей. Вы много сервисов знаете, где хотя бы по 10000 пользователей в день прилетает?
Зато миллионы сервисов не открыты, потому что при создании потратили деньги и время на преждевременную оптимизацию...
Sanes: Да бог с ним, это решаемо в рамках 1000-10000 баз. Да, надо будет посидеть и подумать, как составить такой запрос. Да, он будет медленный шо пипец, но сводную информацию можно закэшировать после запроса или делать её по расписанию. По факту, нет и 100 пользователей, о чем я написал ниже. Функционал и масштабируемость - дело решаемое когда сервис работает. А делать сейчас - время тратить в пустую.
Александр: Вы сейчас придумываете находу возможные варианты будущего, не имея базу пользователей даже и из 100 человек. И не говорите о том, сколько в базе таблиц/тип таблиц и какого они размера. Одно дело когда разговор о таблицах по 35млн и другое по 1000.
Если у вас список таблиц из 1000 штук и вы при подключении открываете одну базу, то Mysql как минимум должен найти её в этом списке. Я предполагаю, что индексов на базы данные просто тупо нету. И при большом количестве, большая часть времени выгрузки данных будет уходить не на запросы поиска в таблицах, а поиск самой базы в длинном списке.
Спасибо добрый человек. Второй день - полет нормальный. Режет все и наконец-то страницы летают. Я уж подумал, придется проксировать через собственные мощности, чтоб сервер все резал и отдавал.
Илья Шатохин: Спасибо за очереди, попробую использовать для запуска async.parallel для асинхронного раскладывания заданий по ws. Но чувствует это для меня высший пилотаж. Особенно если по определенному сокету подвиснет задание, а там уже следующее добавилось. Может жесткий шторм образоваться при наличии большого количества заданий на один сокет.
Илья Шатохин: Единственный момент который беспокоит, а если тело функции еще доконца не выполнелось, это как решать? Ведь интервал будет просто запускать дальше, если я правильно понимаю. Пока у меня в голове решение лок переменную какую-то забацать и при запуске функции проверять её значение. Если лок стоит, значит пропускать выполнение функции и завершать.
Yustas Alexu: Походу вы тот самый первый, кого это удивляет.
Если перечитать последние 5-7 вопросов моих, то станет понятно, что речь идет о взломе корпоративного софта. Поэтому особо разработчиков не привлечь, это уже будет нарушением политики конфиденциальности. По факту, я называю это оптимизацией. Я собрал то что собрал за 8-9 часов личного времени которое нашел на неделе. А по итогу, мне как минимум не надо ездить 2 раза в неделю в компанию и некоторые "идиотские" моменты теперь не раздражают, которые насоздавали наши сисадмины.
Тимур Шемсединов: Спасибо. Ладно, с богом. Попробуем с незнанием JS все перекроить под одну адскую машину. Отпишусь в конце, как оно и стоила игра эта чего-нибудь
Виталий: Селекты не одинаковые. База выглядит примерно следующим образом: id / script_id / send / create_at / update_at / state . Каждый скрипт забирает по script_id то что он должен сделать и обновляет статус. А INSERT в таблицу идет от отдельного приложения. Там не много. Таблица за часок всего на 15000-25000 вырастает. По завершению делается TRUNK. Чтоб базу не растить, данные не нужны особо.
Виталий: Меня сейчас больше интересует вопрос не рухнет скрипт. Я очень часто обжигался с недоязыками, который при большом потоке просто обваливались и посылали в жопу. Тут ведь получается создаются обертки WebSockets в количестве 700 штук, которые уже в асинхронном режиме выполняют минимальные действия: прием данных + ping/pong. А после идет уже некий контроллер, который пусть и линейно но раскидывает ws.send при необходимости.
Виталий: Во-первых не смотря на то, что железо тянет пока не плохо. Притом что база ещё херову тучу запросов обрабатывает по другим таблицам. Но есть нюансы. Когда начинают работать скрипты: База начинает жрать RAM, Скрипты жрут RAM, IOPS на SSD просто дикий. INSERT в эту таблицу иногда провисает на 1сек (это не критично). Все остальные запросы по другим таблицам в особенности SELECT начинают провисать, не критично. в рамках сотых миллисекунд. Я особо не измерял, но вот выкладка запроса к таблице из PHPMYADMIN:
Скрипты не работают (156 соединений к базе): Отображение строк 1000 - 1029 (32030667 всего, Запрос занял 0.0007 сек.)
Тот же запрос со скриптами (821 соединений к базе): Отображение строк 1000 - 1029 (32031269 всего, Запрос занял 0.03288 сек.)