Не привык торговаться, видимо потому что раньше сам торговал, и не люблю когда сбивают цену. Могу поторговаться если товар б/у и нужен ремонт или обслуживание какой-то части, но в целом ок. Свой торг всегда обосновываю. Или прям если очень хочеться купить, но не хватает немного. Но на большие суммы скидку никогда не просил. Больше всего не понимаю дебилов, которые могут при цене грубо говоря в 1000 сказать "За 300 заберу". Бери конечно, но не у меня.
Два чая этому господину.
Ну правильно, выше сделайте set $noname dram;
Не сочтите за грубость, но во-первых, учитесь читать логи, во-вторых, учитесь гуглить (желательно на английском языке). Вы же на форуме поисковых систем. Это очень полезные навыки, которые экономят время.
https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/
edogs, не-не, религиозный фанатизм это не про меня. Я придерживаюсь мировой практики в разработке, знаю что такое trade off при выборе какого-то инструмента. Я привел вам доводы, почему InnoDB лучше в данном случае. От вас я пока услышал только вот это:
У вас все относительно. Небольшой и средний сбой - нет такой классификации. Есть битые индексы, есть умерший диск, и т.д. Что такое "небольшой" и "средний" сбой известно только вам, как, в прочем, и "относительно простые запросы".
Ну и NoSQL вы предложили, не я, так что с религиозным фанатизмом вы явно не по адресу.
Когда приведете хоть один довод, почему MyISAM в данном случае лучше, тогда и будет вам
Бггг, ну и бред. Т.е., берем любую TSDB и пишем туда. Отличный совет. Уже на этом можно прекращать дискуссию, но ладно.
Да.
Это прямо из документации вырезка.
Какой, если я их отключу, а буду использовать redo log из InnoDB?
Да, как и все другие статьи вышедшие 10 лет назад.
Я бы ещё понял если бы вы посоветовали использовать MyISAM под табличку которая никогда не изменяется, используется под read-only, и в ней 500 не важных строк.
Ладно, не хочу время тратить на этот бессмысленный спор. Используйте и дальше MyISAM, пока его не выкинут из MySQL.
Когда пишете NoSQL, пишите какая именно. Бывают варианты для полностью противоположных задач.
На самом деле, в некоторых случаях поиск по JSON даже быстрее, чем по реляционной модели.
Я так понял, там особо нечего нормализовать. Есть какой-то идентификатор, и куча байт которые нужно вернуть.
Да, действительно, обратите внимание на движок, который при малейшем сбои может покорраптить все таблицы. Приведите примеры, на каких запросах может быть тормознее (кроме COUNT(*))
Кстати, да. Но если нужно сжатие, я бы взял MyRocks, мы так одну базу до 400Гб ужали (с 1Тб)
Сейчас вот как раз есть одна толстая таблица на почти 3 млрд строк:
SELECT table_rows FROM information_schema.tables WHERE table_name = 'my_table_name'; +------------+ | table_rows | +------------+ | 2795222610 |
А вот время выборки по PK:
379 rows in set (0.017 sec)
Таблица без партиций, кстати. Можно сделать PARTITION BY HASH(col) PARTITIONS 20; и будет все ещё быстрее работать
Clickhouse не про это, она коллоночная база данных, она скорее про аггрегацию значений и постоянную запись, и про всякие паттерны 3д кубов и прочего. Это OLAP, автору на сколько я понял нужно OLTP.
Зачем вам JSON тип? Вы по нему искать собираетесь? Если да, то лучше PostgreSQL, или на крайняк Mongo. Если искать по JSON нет нужды - берите любую СУБД, поиску присваиваете идентификатор, JSON не храните в типе JSON, т.к. там валидация происходит. Просто берите BLOB и храните массив байт.
На счет справится/не справится, справится и с бОльшим количеством. Делаете партиции и все будет работать вполне себе.
А вообще, структура ваших данных и необходимые выборки до конца не ясны.
Это к ТСу было.
На самом деле, я бы не делал ставку на "бесплатную модель". Вам нужно иметь много VPS разнесенных по миру, чтобы проверять доступность. Но дело ваше. Если руки чешуться - то можно и сделать. Опыт в любом случае получите.
Ну тяжеловато, да, на дальняки не подходит, но мы пока на дальняки не ездим особо. Если нужно - я поднимаю седло в верх чтобы нога почти полностью выпрямлялась.
