Так проблема наверное не в языке, а в том, кто писал код?
Я писал в свое время код на перле, писал много, и наш код выглядел на порядки лучше, чем я сейчас читаю на «правильных» языках. Просто писать надо уметь.
По крайней мере в андроид-магазине таких нет. Есть глючнейшее weather undergroud (которые купили intellicast), но оно настолько часто падает, что его пришлось снести, ибо пользоваться невозможно. Поэтому я так упорно выясняю, что же на самом деле надо использовать :)
С одной стороны меня интересует подмосковье, но это не особо, там даже если не угадаешь с погодой, последствия не очень критичны. Больше интересует Кавказ — Приэльбрусье, там ошибка в погоде намного дороже обходится.
Intellicast сожран weather underground, а его мобильное приложение стало настолько отстойным, что в плеймаркете собрало отсилы 2.5 балла. Есть чтото адекватное с хорошим качеством прогноза (мобильное)?
Когда учился в институте и работал, была машина, но на ней не было иксов, была только текстовая консоль. Выбора не было — или использовать ее, или не использовать ничего. Норм, жить можно — несколько месяцев вполне продуктивной работы с С/С++, gdb и т.п. Мышой можно пользоваться через gpm, для файлов — mc (я и сейчас им пользуюсь), почта — через pine, в интернет ходить — links и lynx, звук тоже чем-то запросто рулился из консоли, не помню уже, лет 15 прошло… Ну и vim конечно же. В общем, если для работы — то вполне рабочий вариант.
На первом слайде нарисовано, что эластик не сжимает данные. Но это не так: «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) и поправить файлы, которые испортились?
Так вот значит надо это лаборатории решать проблему хранения спелого вкусного персика, а не ценника. Люди ходят в магазин за нормальными продуктами, а ритейлеры все нормальные продукты заменили на непонятно что. Нормальное еще как-то можно купить на рынке, но скоро уже все рынки ликвидируют под разными предлогами…
В общем не тем занимается лаборатория, совсем не тем.
Почему-то сразу вспомнился microsoft flight simulator...
Я писал в свое время код на перле, писал много, и наш код выглядел на порядки лучше, чем я сейчас читаю на «правильных» языках. Просто писать надо уметь.
Intellicast сожран weather underground, а его мобильное приложение стало настолько отстойным, что в плеймаркете собрало отсилы 2.5 балла. Есть чтото адекватное с хорошим качеством прогноза (мобильное)?
«Никак не могу», «нисколько не сожалею».
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, или на таких объемах это нежелательно, или может запустить-то надо, но когда нагрузка спадет. Это уже область нюансов, где единственного верного решения нет.
Спасибо, может быть пригодится, не нам, так другим.
В общем не тем занимается лаборатория, совсем не тем.