На первом слайде нарисовано, что эластик не сжимает данные. Но это не так: «Does Elasticsearch automatically compress? Yes. The default compression is LZ4, but you can use DEFLATE, which is higher compression at the cost of more CPU to compress further, and a slightly slower indexing rate.» discuss.elastic.co/t/does-elasticsearch-automatically-compress-data/93161/2
Мне кажется, что Вам следует устранить пробел в википедии и написать статью про такой насос, а то вот пошел гуглить — ссылка на статью есть, а самой статьи нет.
С данными все понятно, оно так и есть (кстати, у нас стоит бинарная репликация в Ваших терминах), но вот при выполнении DDL на мастере, как по мне, наиболее логично все-таки менять структуру таблицы на слейве одной DDL командой, чем построчно, потому что структуру таблицы все равно менять надо, но зачем потом поштучно пустые значения новой колонки синхронизировать?
Вопрос в том, что именно Вы хотите получить. Если Вас не пугает время выполнения и лишняя нагрузка и Вам реально нужно более-менее точное значение, то COUNT как раз то, что нужно.
Но даже пока вы считаете SELECT COUNT, значения могут быть добавлены или удалены, т.е. не факт, что значение будет точным.
Но часто точное значение и не нужно, и тогда приходят альтернативные варианты. Т.е., например, исходя из того же SHOW TABLE STATUS Вы можете приблизительно понять, точно ли Вы хотите запустить SELECT COUNT, или на таких объемах это нежелательно, или может запустить-то надо, но когда нагрузка спадет. Это уже область нюансов, где единственного верного решения нет.
Не было особой нужды, но судя по описанию того, как это работает, сей тул действует примерно так же, как я предлагал ручной алгоритм, правда там еще триггеры наброшены для апдейта новой таблицы, если были изменения за время процедуры.
Спасибо, может быть пригодится, не нам, так другим.
Если уж мы удосужились вытащить диски и переставить их в другую машину, то зачем все эти пляски с systemd, если по сути надо просто смонтировать диск (ну если надо — то прогнать fsck) и поправить файлы, которые испортились?
Так вот значит надо это лаборатории решать проблему хранения спелого вкусного персика, а не ценника. Люди ходят в магазин за нормальными продуктами, а ритейлеры все нормальные продукты заменили на непонятно что. Нормальное еще как-то можно купить на рынке, но скоро уже все рынки ликвидируют под разными предлогами…
В общем не тем занимается лаборатория, совсем не тем.
Если уметь правильно намотать портянки — берцы еще тот выбор. И сохнут портянки быстро, а из ботинок воду вылил и пошел дальше, в то время как мембранные со всякими пористыми вставками сушить — не пересушить.
Для розжига, как ни странно, очень подходят обертки от батончиков РотФронт :)
Они промасленные и очень хорошо горят и не мокнут. Да и тащить лишнего не надо — конфету съел, бумажку в карман.
В разных случаях по-разному, где-то хранятся атрибуты, где-то нет. Если это просто оригинальное объявление о продаже недвижимости — то оно всегда html, никаких атрибутов, но зато есть оно же разобранном виде, и это разобранное уже лежит в базе, причем не в одной. В других случаях хранится мета-инфа: размер картинки, тип данных внутри, оригинальное название…
Согласно указанной Вами статье, «большинство систем будут проседать при нагрузке/соотношении в районе 2.»
Но я исходил из нашего опыта на наших машинах, и в районе 2х более-менее, обычно меньше, 5-6 — это усердное копирование файлов, требует мониторинга админа, ибо чревато скачком, а при 8 уже клиенты ругаются.
Мы поэкспериментировали с прозрачным сжатием на zfs: на SSD положили mysql базу. Пока радуемся жизни, все стало в разы быстрее, чем на обычных HDD, и при это влезло на SSD (размер базы сейчас порядка 1.3 Тб). С файлстораджем так не экспериментировали, но почему бы и нет.
«Никак не могу», «нисколько не сожалею».
ru.wikipedia.org/w/index.php?title=Паромасляный_диффузный_насос&action=edit&redlink=1
mysql> select count(*) from offer;+-----------+
| count(*) |
+-----------+
| 681382000 |
+-----------+
1 row in set (1 min 34.53 sec)
Но даже пока вы считаете SELECT COUNT, значения могут быть добавлены или удалены, т.е. не факт, что значение будет точным.
Но часто точное значение и не нужно, и тогда приходят альтернативные варианты. Т.е., например, исходя из того же SHOW TABLE STATUS Вы можете приблизительно понять, точно ли Вы хотите запустить SELECT COUNT, или на таких объемах это нежелательно, или может запустить-то надо, но когда нагрузка спадет. Это уже область нюансов, где единственного верного решения нет.
Спасибо, может быть пригодится, не нам, так другим.
В общем не тем занимается лаборатория, совсем не тем.
Они промасленные и очень хорошо горят и не мокнут. Да и тащить лишнего не надо — конфету съел, бумажку в карман.
Но я исходил из нашего опыта на наших машинах, и в районе 2х более-менее, обычно меньше, 5-6 — это усердное копирование файлов, требует мониторинга админа, ибо чревато скачком, а при 8 уже клиенты ругаются.