ваш вопрос практический или теоретический? если практический, то ответ в виде rsync я вам уже назвал. если теоретический, то cs.anu.edu.au/techreports/1996/TR-CS-96-05.pdf или если прочитать пдфку окажется непосильной задачей, то маленький кусок как раз есть в википедии.
ничем не подкреплены? просто посмотрите, что значит значение 2, подумайте, возможно ли нарушение consistency, во всех ли ситуациях скорость важнее чем consistency, и если окажется что нарушение возможно и скорость не всегда важнее, то это значит, что ваш совет не универсальный.
это в целом правильный совет (и советы 5..8 в большинстве случаев тоже правильные), но они все не универсальные. вашу позицию я понял, свою вроде бы тоже высказал, так что давайте, наверное, прекращать уже этот бессмысленный спор.
следует разделять большой поток быстрых однотипных запросов и маленький поток тяжёлых сложных запросов. первое обычно называют highload, второе — high performance, hpc или big data. судя по словам «Проблема в том, что время выполнения запросов очень большое, ~3 минут», я предположил, что у автора нету потока в сотни запросов в секунду.
данных для того чтобы дать совет не с потолка здесь недостаточно. вы не знаете, какие ещё данные есть на сервере и какие ещё запросы используются. и сколько каких запросов. а от этого очень сильно зависит ответ. не говоря уже о то, что вы даже не знаете, ssd там или нет. большая ли write-нагрузка или нет. innodb_flush_log_at_trx_commit=2 не годится для абсолютно любых серверов.
и у меня достаточно много опыта работы с mysql, чтобы понимать, что ходить по QA, просить показать конфиг и после этого сразу же давать космически нелепый совет — это довольно глупое поведение. но я вас не виню, сам когда-то такой был: )
советы по конфигурации вроде бы ок, но они для случая «большой поток быстрых запросов». в вашем текущем случае, автор, проблема не в конфигурации, а в конкретном запросе и в индексах, поэтому стоит вначале решить эту проблему и уже потом конфигурировать. но на основе статистики (которую percona server даёт в достаточном количестве), а не на основе случайного угадывания на кофейной гуще людьми из интернетов.
оптимальные настройки зависит от профиля нагрузки.
это плохой совет.
если индекс будет (task_id, checked,taken), то запрос select task_id from tasks_pending where checked=0 and taken=0 group by task_id limit 50 только проиграет от использования этого индекса, причём сам он его использовать не будет (потому что mysql сравнительно умный) и вам придётся заставлять его делать плохое через форс индекс.
я увидел, что болванка, и написал, что сайта нету. мне сказали, что я «не увидел сайта» — а я ответил, что это не так.
верстальщики в mamba.ru, afisha.ru и mail.ru стоят примерно столько, сколько я написал. в mail возможно чуть больше.
я не говорю, что у вас всё именно так. естественно, я немного сгустил краски. но именно так вас можно воспринимать. про то, что ваши дела сами всё покажут — это правильный подход.
> Что-то мне подсказывает, что для сборки нет необходимости в 4Gb оперативной памяти
это зависит от проекта. у меня в проекте на 15к строк было много шаблонов, и компилятор ел до 3Гб в пике (а собиралось всё минуты за полторы). всего у меня было 8Гб, запускать 2 потока — нормально, больше двух — уже своп и тормоза.
использование процессора близко к 100%, использовать ramdisk пробовал (без существенного улучшения), и никакого выигрыша от ssd не было бы тоже.
я погуглил, преже чем писать. ebr.ebrit.ru/ — это же он? это пока не сайт. о каких «достойных и конкурентных условиях» вы говорите, если рыночная цена хорошего верстальшика в москве — 70-90?
и либо я написал всё правильно, либо вы берёте на работу средних или плохих верстальщиков и средних или плохих программистов, причём последний вариант даже хуже всего
такая же история, кстати, не только у нас, но и у Facebook (0% изначального кода), и у Twitter (которые вообще поменяли платформу), и у многих других ресурсов
я рассказываю, основываясь на своём опыте работы с большим и сложным проектом с более чем 20 разработчиками и более чем 5ти-летней историей. и который работает на более чем 100 серверов.
> сколько операций в секунду даст выполнить база когда к ней будут обращаться с одного потока
> сравнить производительность указанных БД для нескольких болльших плоских таблиц и простейших запросов
я вижу тут противоречие. нет, ну на вопрос «сколько операций в секунду даст выполнить база из одного потока» ваши тесты отвечают. я именно поэтому пример с большим пальцем ноги и привёл.
SQLite — встраиваемая база. её можно скорее всего сравнивать с другими встраиваемыми базами. kyoto/tokio cabinet например.
Postgres/mysql и redis — разные весовые категории, у одних есть транзакции, тьюринг-полный sql, гарантированная консистентность, работа с данными которые значительно превышают объём ram и куча других штук, и redis, то есть простейшие структуры данных лежащие в оперативке + небольшой слой для поддержания персистентности.
вы декларировали цель «сравнить производительность указанных БД для нескольких болльших плоских таблиц и простейших запросов».
ваша задача, даже если бы все меряли правильно, не поможет узнать «производительность больших плоских таблиц и простейших запросов». и к очереди она не имеет никакого отношения, потому что у очереди есть ровно 2 операции: «взять» и «положить».
и это не говоря уже о том, что понятие «производительность» очень широкое и его можно трактовать как угодно. некоторые меряют скорость работы единичных аналитических запросов, которые выполняются десятки минут. некоторые меряют время отклика определенного количества мелких запросов с определенного количества потоков. некоторые меряют максимально возможное количество мелких запросов но чтобы время отклика не превышало пороговое, а количество одновременных запросов подбирают.
а что меряете вы? вы меряете задержки у единичных неконкурентных запросов. померяли. результаты ожидаемы.
> Поиск по сбаллансированному дереву эффективней бинарного поиска по отсортированному массиву
почему это? и там и там — O(log(n)). асимптотика одинаковая.
но отсортированный массив аналогичен идеально сбалансированному дереву, а авл или красночерные такими не являются и выше идеального в среднем в 1.3-1.4 раза.
второе преимущество массива — локальность данных. чем глубже вы в дереве, тем меньше ваш working set (а в случае с деревом память соседние элементы могут отстоять далеко в адресном пространстве; тут можно сделать node pool и выделять память для элементов оттуда)
