|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Подскажите статьи или идеи по построениею шардинга для запросов сложнее чем просто SELECT name FROM accounts WHERE user_id = :id
Т.е. для запросов с JOIN когда обе таблицы в джойне распределенные или для распределенных таблиц сообщений по типу
CREATE TABLE user_mess
(
user_id_from INT(11),
user_id_to INT(11),
mess_text TEXT
)
Вообщем по MapReduce. Если есть желательно для продвинутыхи на русском, но если есть хорошие можно и на английском.
Неактивен
Это разные вещи. MapReduce — это алгоритм преобразования данных. А
шардирование — это способ хранения информации. Я бы сказал, что это
ни разу не связанные вещи.
Объединять шардированную информацию не получится. Но, к счастью,
обычно это и не нужно. Если нужно — Вы неправильно придумали шарди-
рование 
В крайнем случае — часть информации нужно будет дублировать
между шардами.
Неактивен
Т.е. при шардировании алгоритмы MapReduce не используют в принципе ни на уровне SQL ни на уровне WEB?
Может тогда предложите какие-то статьи по наиболее сложным задачам которые решаются шардированием?
Неактивен
Я могу придумать задачку, которая использует и то, и другое 
Например: у Вас есть гора яблок и груш. Нужно посчитать их количество.
Этап Map: мы для каждого элемента кучи применяем операцию сравнения
с яблоком. Успешные элементы складываем в одну корзину, неуспешные —
в другую. Этап Reduce: считаем количество объектов в каждой из корзин.
Корзины — это различные шарды
Пока Вы не опишете свою задачку — Вы не сможете получить ответ, который
Вас устроит на 100%.
Неактивен
MapReduce относиться к функциональному программированию.
Map – распределение задач на самостоятельные СУБД.
Reduce - параллельная свертка предварительно обработанных данных.
Если в примере с яблоками и грушами, то разложить их по корзинам это задача на уровне ETL.
А затем запрос на подсчет яблок и грушь:
Map - разделить исходный запрос на 2 запроса, 1 - подсчет в корзине с яблоками, 2 - подсчет в корзине с грушами
Reduce - свернуть полученные результаты, в данном случае просто объединить
Моя конкретная задача найти статьи по шардированию, с описанием решения конкретных любых задач.
Если ещё более конкретно, то как реализуется
SELECT T1.id, sum(T2.par) FROM Table1 T1 INNER JOIN Table2 T2 ON T1.id = T2.id GROUP T1.id
где (2 варианта)
а) T1 - реплицируемая таблица (находится на каждой ноде, избытычность данных)
T2 - распределенная таблица
б) T1, T2 - распределенные таблицы
Неактивен
Брр, есть котлеты, а есть коты. Можно совмещать, а можно не совмещать.
Не знаю, как объяснить по другому. Ну и фиг с ним, переубеждать не буду
JOIN можно делать только между табличками, которые находятся в пределах
одного экземпляра СУБД. Поэтому Ваш вариант а будет работать с учетом
объединения выборок в клиентском приложении. Вариант б в общем случае
нужно будет реализовывать последовательным чтением. Например, SELECT
T1.id из всех шардов T1, SELECT T2.* WHERE id IN (перечисление).
Статьи писать по этому поводу вряд ли кто-то будет, т.к. задача тривиальная
в том виде, что я ее описал, и совершенно неподъемная с точки зрения реали-
зации (не в плане написать нельзя, а в плане передать миллион ID в запросе).
Как правило, никого не интересует полное объединение таблиц. Есть некоторое
условие сортировки и LIMIT. Именно от них надо плясать.
Неактивен
Я занимаюсь реализацией алгоритмов MapReduce для DWH. Параллельно интересуюсь шардированием. Как эти задачи решаются в принципе я знаю. Мне интересно как эти же или похожие задачи решают другие люди. Там где применяется шардирование видимо в задачах такой сложности нету смысла.
Уточнение про Map к тому, что Map относится к разделению задач(исходного SQL-запроса), а не к объектам над которыми эти задачи выполняются.
А такие пару вопросов, может знаете на практике.
1. При вставках записей решение о том на какой шард слать (INSERT)SQL-запрос принимается на стороне WEB(PHP) или на стороне СУБД(через тригеры)?
2. В каком случае применяется шардирование: нехватка ОЗУ и пропускной способности HDD или же нахватка ресурсов CPU? Понятно что бывают разные случае, но в общем случае, который допустим встречался у вас.
3. Не легче ли использовать файловый кэш для держания часто используемых частей БД (MySQL) в ОЗУ, вместо использования memcached?
Неактивен
1. На стороне приложения. Не обязательно web. Нет смысла делать через
триггеры — получается неустойчивая система.
2. Бывают разные случаи
3. Легче, учитывая, что файловый кэш используется сам, а для исполь-
зования memcached надо еще что-то писать
Неактивен
paulus написал:
1. На стороне приложения. Не обязательно web. Нет смысла делать через
триггеры — получается неустойчивая система.
2. Бывают разные случаи
3. Легче, учитывая, что файловый кэш используется сам, а для исполь-
зования memcached надо еще что-то писать
1. Не обязательно веб, а тогда где и как?
2. Не жадничайте В DWH тоже бывают разные случае, но в подавляющем большинстве это дисковое IO. Но в DWH мало пользователей, большие объемы данныех и тяжелые аналитические запросы.
3. Если легче, то зачем используют этот memcached?
Неактивен
1. Не поверите, MySQL используют не только в веб-приложениях
2. Я не жадничаю. Правда, бывает, когда упираются в IO, иногда в процессор,
иногда даже в место на дисках. Еще можно упираться, например, в сеть (и тогда
в ход идет геошардирование), и т.п.
3. memcached используют, потому что это быстрый и простой способ сохранить
hash-value. Только вот на диск эта штука не попадает. Зато используют базы
hash-value, которые попадают на диск. Вообще, есть много технологий, которые
используют
Неактивен
А почему бы MySQL не использовать для хранения hash-value, учитывая, что файловый кэш используется сам?
Насколько велика разница в скорости между хранением закэшированных данных в MySQL и memcached, примерно в 2, 10, 100 раз?
Неактивен
Сложный вопрос. Если использовать hash-value, то можно еще и задействовать
HandlerSocket. С него я снимал 120 тысяч запросов выборки в секунду на своем
ноутбуке (т.е. то, что говорят, что на сервере снимают 400-500 тысяч rps —
вполне реально, кажется). Я не думаю, что с memcached Вы снимете сильно
больше, а вот то, что MySQL при этом еще и сохраняет данные на диск, — не-
сомненно, плюс
Неактивен
Почитал про HandlerSocket. http://tokarchuk.ru/2010/10/nosql-in-my … ove-mysql/
Запросов в сек использование CPU
Обычный SQL запрос 105,000 %us 60% %sy 28%
memcached 420,000 %us 8% %sy 88%
HandlerSocket 750,000 %us 45% %sy 53%
Действительно задумка хорошая, для хранящихся данных в памяти использовать плагин NoSQL.
Исключаем задержки на:
1. Парсинг SQL
2. Построение плана запроса
3. Открытие/закрытие таблиц
А не используют Prepared Statements ?
Понятно, что решаются только первые 2 пункта. Также группировки пользовательских подключений не происходит. Но пользоваться уже можно даже на обычном хостинге без дополнительных плагинов. Т.е. будет медленнее чем HandlerSocket, но быстрее чем в статье по ссылке для "Обычный SQL запрос".
Неактивен
Prepared statements не дадут такой производительности, разумеется. По сути,
Вы избавляетесь только от п.1, и то только частично (ведь запрос EXECUTE...
надо всё равно парсить). Что касается плана — он строится каждый раз (т.к.
в зависимости от входных параметров запрос может идти разными путями.
Неактивен
