гитхаб и битбакет точно так же работают

Как?

Идентификатор может обозначать как пользователя, так и организацию

Вот чем мне нравятся графовые базы... никаких головняков за таблицы и прочий бред. Заноси в нее че хошь. Хоть черта лысого. И указывай связи с весами и подробностями.

только не заново это все

Вот чем мне нравятся графовые базы... никаких головняков за таблицы и прочий бред. Заноси в нее че хошь. Хоть черта лысого. И указывай связи с весами и подробностями.

И чё по скорости выборки?

http://www.peoples.ru/character/movie/phil_connors/connors_1.jpg

И чё по скорости выборки?

ну так же индексируешь и вперед.

И чё по скорости выборки?

есть варианты для хайлоада

А где можно почитать?

А где можно почитать?

http://www.datastax.com/products/datastax-enterprise-graph

http://www.datastax.com/products/datastax-enterprise-graph

А для неканадцев?

А для неканадцев?

в смысле по русски? чет даже не задумывался о таком

А для неканадцев?

тут вот можно поигратся

http://console.neo4j.org/?_ga=1.142652725.1675949446.1479403402

http://www.datastax.com/products/datastax-enterprise-graph

Что за дичь сейчас влил в мозг. Это канал ИТшников или маркетологов? Накой леший мне куча воды продажной, да ещё на албанском?

Что за дичь сейчас влил в мозг. Это канал ИТшников или маркетологов? Накой леший мне куча воды продажной, да ещё на албанском?

блин ну есть еще куча всяких статей сравнений и прочего. но там тож все с закосом под маркетинг. вариант простой подними любой сервак и потыкай в него

Не, я уже глянул и понял, что создовади велосипед, а вышел bmx

Не, я уже глянул и понял, что создовади велосипед, а вышел bmx

ну как бы да. ничего нового не создали. но удобно

Что за дичь сейчас влил в мозг. Это канал ИТшников или маркетологов? Накой леший мне куча воды продажной, да ещё на албанском?

Вот именно, это канал IT или где? С какого перепугу стал требоваться перевод с английского?

Вот именно, это канал IT или где? С какого перепугу стал требоваться перевод с английского?

Я не требовал, я поинтересовался ;)

cross-post коллеги, нужен совет ?

Девопсы, если mysql пишет в логах: [ERROR] Cannot find or open table databasename/tablename from the internal data dictionary of InnoDB though the .frm file for the table exists. это уже не вылечить? Только dump с параметром -f и снова накатывать?

попробуй спросить не девопсов, а дба, может откликнутся

попробуй спросить не девопсов, а дба, может откликнутся

я же написал что это кросс-пост

Девопсы, если mysql пишет в логах: [ERROR] Cannot find or open table databasename/tablename from the internal data dictionary of InnoDB though the .frm file for the table exists. это уже не вылечить? Только dump с параметром -f и снова накатывать?

Так у тебя ибдшный файлик есть? И фрмка лежит? Можно попробовать сделать импорт тэйблспейс:) не уверен что сработает

Если табличка не нужна конкретная то можно мувнуть фрмку куданить

А почему бинарики в mysql не стрипают (strip -s)?

You are broking the debugging info :). You can safely strip it. понял

Так у тебя ибдшный файлик есть? И фрмка лежит? Можно попробовать сделать импорт тэйблспейс:) не уверен что сработает

ноу. но руками восстановил. теперь дело за бэкапами

Подскажите, почему так выходит - http://pastebin.com/FpVtqsYF ?

ноу. но руками восстановил. теперь дело за бэкапами

Что восстановил руками?;)

генерим число от 50 до 5051 потом от единицы отнимает его получаем то что получаем

Есть задача. Надо сделать максимально быстрой отклик в любой части планеты. Проект - рекламный трафик. Нужно записывать КАЖДЫЙ переход в базу, при этом делать это максимально быстро. В момент захода на сервер скрипт делает 2 запроса выборки данные и до трёх INSERT´ов. Сейчас сделано по принципу 1 мастер и 3 репликации. Мастер стоит в Ирландии, рядом сервер со скриптом, там код отдаётся за 9мс, второй слейв стоит в северной вирджинии, там время отдачи 1с, ещё один в мумбае, там примерно 2с. Задержка из-за INSERT´ов, это время максимальное, при всех трёх (один минимум). Задача: поднять локации по всему миру с минимальным откликом. В планах решить сразу несколько вопросов: 1. Подтянуть мастера к удалёным точкам 2. Сделать резервные копии на случай выпадения мастера по жести Выбранная схема: Мультимастер Актив-Актив, 3 штуки, в Ирландии, Сингапуре и Северной Вирджинии, репликации "все на всех", чтобы не было зависимости от "кольца". Далее у каждого мастера будут ещё свои слейв репликации по стандартной топологии звезды мастер-слейв актив-пассив. Не стал сразу всё делать, а вынашиваю идею уже полтора месяца и постепенно начитался и наслушался, но пора начинать. Постепенно понял, что мне не нужно реплицировать ВСЕ данные во все стороны. А именно, данные деляться на 3 типа: 1. Записи трафика во время прохода, один проход одна стрoка в таблице 2. Данные из админки, настройки компаний и прочая шелуха 3. Сводные данные трафика, раз в час идёт выжимка из первого типа данных, где групируется по источнику, чтобы по ним потом отдавать гибкую статистику. Первые данные надо раскидывать репликой Мультимастер Актив-Актив, это для резервного бэкапа и для других вычислений. Вторые данные в принципе по сути будут всегда писаться из админки, её я пока не планирую разносить, будет в одном месте, писать будет в один мастер (если тот не отвалится), потому не уверен, есть ли смысл её реплицировать по той же схеме. Третьи данные, это вообще жесткая такая нагрузка на базу, когда надо несколько миллионов, а может и несколько десятков миллионов прогнать математикой и записать. Потэтому не сильно хочется хочется грузить все мастера такой задачей, было бы интересней придумать схему, где скрипт, который это делает, опрашивал бы все 3 мастера на предмет загруженности ЦПУ, выбирал бы самый слакающий и на нём гнал, а остальным передавал row based репликацию. Либо же эту сводную базу не реплицировать, а каждый будет делать из своих данных, учитывая, что раз в час он обновляет не только часовую сводку но и немного предыдущей, то любые лаги репликации будут догоняться. В качестве ДБ сервера подумываю взять последнию Перкону, она базируется на последнем mysql, а значит там есть и многопоточная репликация и паралельная репликация. Какие подводные камни я уже наметил: авто инкреминенты надо юзать с настройкай шага и оффсета забыть про юник ключи в мастер-мастер схемах забыть про триггеры, процедуры и прочие безконтрольные элементы, которые могут сломать репликацию Не использывать запросы из разряда генерируемых сервером или основывающиеся на других данных, которые могут быть разными на разных мастерах. Помогите котику найти брод в этом океане подводных камней. Просьба: Не предлагайте уйти от мультимастера. Всё остальное преветствуется ^_^

Могу предложить уйти от MySQL в сторону tarantool, и подумать хорошо над архитектурой.

Могу предложить уйти от MySQL в сторону tarantool, и подумать хорошо над архитектурой.

NoSQL?

вопрос не в том что SQL или noSQL, мы есть опыт построения на постгресе, и не могу сказать что всегда это правильно. Особенно расчеты всяких CPMов.

Могу предложить уйти от MySQL в сторону tarantool, и подумать хорошо над архитектурой.

https://en.wikipedia.org/wiki/Tarantool Прочитал и не увидел не одной маломальской причины в моём кейсе это использовать. Можно поподробней описать смысл Вашего предложения?

Если правильно расположить сервера входящих данных, отдачи данных и собственно сервера расчетов, подозреваю что тарантул уделает традиционные СУБД по скорости

Мнение мое, необязательно правильное, но сейчас я бы в эту сторону смотрел.

Есть задача. Надо сделать максимально быстрой отклик в любой части планеты. Проект - рекламный трафик. Нужно записывать КАЖДЫЙ переход в базу, при этом делать это максимально быстро. В момент захода на сервер скрипт делает 2 запроса выборки данные и до трёх INSERT´ов. Сейчас сделано по принципу 1 мастер и 3 репликации. Мастер стоит в Ирландии, рядом сервер со скриптом, там код отдаётся за 9мс, второй слейв стоит в северной вирджинии, там время отдачи 1с, ещё один в мумбае, там примерно 2с. Задержка из-за INSERT´ов, это время максимальное, при всех трёх (один минимум). Задача: поднять локации по всему миру с минимальным откликом. В планах решить сразу несколько вопросов: 1. Подтянуть мастера к удалёным точкам 2. Сделать резервные копии на случай выпадения мастера по жести Выбранная схема: Мультимастер Актив-Актив, 3 штуки, в Ирландии, Сингапуре и Северной Вирджинии, репликации "все на всех", чтобы не было зависимости от "кольца". Далее у каждого мастера будут ещё свои слейв репликации по стандартной топологии звезды мастер-слейв актив-пассив. Не стал сразу всё делать, а вынашиваю идею уже полтора месяца и постепенно начитался и наслушался, но пора начинать. Постепенно понял, что мне не нужно реплицировать ВСЕ данные во все стороны. А именно, данные деляться на 3 типа: 1. Записи трафика во время прохода, один проход одна стрoка в таблице 2. Данные из админки, настройки компаний и прочая шелуха 3. Сводные данные трафика, раз в час идёт выжимка из первого типа данных, где групируется по источнику, чтобы по ним потом отдавать гибкую статистику. Первые данные надо раскидывать репликой Мультимастер Актив-Актив, это для резервного бэкапа и для других вычислений. Вторые данные в принципе по сути будут всегда писаться из админки, её я пока не планирую разносить, будет в одном месте, писать будет в один мастер (если тот не отвалится), потому не уверен, есть ли смысл её реплицировать по той же схеме. Третьи данные, это вообще жесткая такая нагрузка на базу, когда надо несколько миллионов, а может и несколько десятков миллионов прогнать математикой и записать. Потэтому не сильно хочется хочется грузить все мастера такой задачей, было бы интересней придумать схему, где скрипт, который это делает, опрашивал бы все 3 мастера на предмет загруженности ЦПУ, выбирал бы самый слакающий и на нём гнал, а остальным передавал row based репликацию. Либо же эту сводную базу не реплицировать, а каждый будет делать из своих данных, учитывая, что раз в час он обновляет не только часовую сводку но и немного предыдущей, то любые лаги репликации будут догоняться. В качестве ДБ сервера подумываю взять последнию Перкону, она базируется на последнем mysql, а значит там есть и многопоточная репликация и паралельная репликация. Какие подводные камни я уже наметил: авто инкреминенты надо юзать с настройкай шага и оффсета забыть про юник ключи в мастер-мастер схемах забыть про триггеры, процедуры и прочие безконтрольные элементы, которые могут сломать репликацию Не использывать запросы из разряда генерируемых сервером или основывающиеся на других данных, которые могут быть разными на разных мастерах. Помогите котику найти брод в этом океане подводных камней. Просьба: Не предлагайте уйти от мультимастера. Всё остальное преветствуется ^_^

вам нужно другое хранилище и другой ответственный за это дело

вам нужно другое хранилище и другой ответственный за это дело

Почему другое?

И какое другое?

о господи, какие автоинкременты

key-value хранилище + PN-счетчики, если они нужны + не-помню-как-они-называются-Sets (OR-sets, кажется), которые разрешают конфликт включен\удален с помощью LWW (лучше, кажется, пока ничего не придумали) + uuid для идентификаторов

потому что судя из описания, кроме key-value ничего не будет

работа с потоком записей это вообще из другой оперы и должно производиться другими вещами, хранилище должно только уметь потоком отдавать свое содержимое тому, кто с этим будет работать

я привык работать с кассандрой, ее бы и взял.

если критически важны конфликты и их разрешение, то лучше riak, но кассандра позиционируется как решение, которое съест любой объем данных, в то время как про riak тупо знаю только о том, что у него все типы данных CRDT (которые придется реализовывать вручную на кассандре)

есть нормальный метод посмотреть позу в бинлоге?

мускул

Позу или по позе данные?

по позе данные

позу саму я знаю

start-from фигню показывает

не ловит ее

Есть задача. Надо сделать максимально быстрой отклик в любой части планеты. Проект - рекламный трафик. Нужно записывать КАЖДЫЙ переход в базу, при этом делать это максимально быстро. В момент захода на сервер скрипт делает 2 запроса выборки данные и до трёх INSERT´ов. Сейчас сделано по принципу 1 мастер и 3 репликации. Мастер стоит в Ирландии, рядом сервер со скриптом, там код отдаётся за 9мс, второй слейв стоит в северной вирджинии, там время отдачи 1с, ещё один в мумбае, там примерно 2с. Задержка из-за INSERT´ов, это время максимальное, при всех трёх (один минимум). Задача: поднять локации по всему миру с минимальным откликом. В планах решить сразу несколько вопросов: 1. Подтянуть мастера к удалёным точкам 2. Сделать резервные копии на случай выпадения мастера по жести Выбранная схема: Мультимастер Актив-Актив, 3 штуки, в Ирландии, Сингапуре и Северной Вирджинии, репликации "все на всех", чтобы не было зависимости от "кольца". Далее у каждого мастера будут ещё свои слейв репликации по стандартной топологии звезды мастер-слейв актив-пассив. Не стал сразу всё делать, а вынашиваю идею уже полтора месяца и постепенно начитался и наслушался, но пора начинать. Постепенно понял, что мне не нужно реплицировать ВСЕ данные во все стороны. А именно, данные деляться на 3 типа: 1. Записи трафика во время прохода, один проход одна стрoка в таблице 2. Данные из админки, настройки компаний и прочая шелуха 3. Сводные данные трафика, раз в час идёт выжимка из первого типа данных, где групируется по источнику, чтобы по ним потом отдавать гибкую статистику. Первые данные надо раскидывать репликой Мультимастер Актив-Актив, это для резервного бэкапа и для других вычислений. Вторые данные в принципе по сути будут всегда писаться из админки, её я пока не планирую разносить, будет в одном месте, писать будет в один мастер (если тот не отвалится), потому не уверен, есть ли смысл её реплицировать по той же схеме. Третьи данные, это вообще жесткая такая нагрузка на базу, когда надо несколько миллионов, а может и несколько десятков миллионов прогнать математикой и записать. Потэтому не сильно хочется хочется грузить все мастера такой задачей, было бы интересней придумать схему, где скрипт, который это делает, опрашивал бы все 3 мастера на предмет загруженности ЦПУ, выбирал бы самый слакающий и на нём гнал, а остальным передавал row based репликацию. Либо же эту сводную базу не реплицировать, а каждый будет делать из своих данных, учитывая, что раз в час он обновляет не только часовую сводку но и немного предыдущей, то любые лаги репликации будут догоняться. В качестве ДБ сервера подумываю взять последнию Перкону, она базируется на последнем mysql, а значит там есть и многопоточная репликация и паралельная репликация. Какие подводные камни я уже наметил: авто инкреминенты надо юзать с настройкай шага и оффсета забыть про юник ключи в мастер-мастер схемах забыть про триггеры, процедуры и прочие безконтрольные элементы, которые могут сломать репликацию Не использывать запросы из разряда генерируемых сервером или основывающиеся на других данных, которые могут быть разными на разных мастерах. Помогите котику найти брод в этом океане подводных камней. Просьба: Не предлагайте уйти от мультимастера. Всё остальное преветствуется ^_^

Тут вам не вполне нужна РСУБД на первом этапе, скорее очереди событий. И уже потом из очередей выбирать и писать в БД

очередь для записи событий можно в тоже же раббите например организовать. а потом фоновый процесс оттуда читает и переносит в в реляционную субд.

Так, видимо придётся вникнуть. Давайте начнём с простого - зачем мне очередь записей?

Так, видимо придётся вникнуть. Давайте начнём с простого - зачем мне очередь записей?

Для предсказуемого времени отклика и уменьшения зависимости между реагированием на запрос и записью в базу, например.

ERROR: S client not available

она позволит аккумулировать нагрузку при краткосрочных пиках, чтобы потом в нормальном режиме ее разобрать

но вообще интересно предыдущих авторов послушать

Для предсказуемого времени отклика и уменьшения зависимости между реагированием на запрос и записью в базу, например.

А как мне транзакциозность поддерживать?

Транзакционность чего, когда, почем и зачем?

она позволит аккумулировать нагрузку при краткосрочных пиках, чтобы потом в нормальном режиме ее разобрать

Пики скорее не краткосрочные будут, а дневные колебания, которые в принципе будут выравнены, ввиду трёх мастеров с охватом всего шарика, тем самым, когда в америке будет ночь, будет писаться "пик" азиатского трафа

Транзакционность чего, когда, почем и зачем?

Тех трёх INSERT´ов

1. Используйте надежные очереди сообщений. Если речь о том, чтобы не терять события.

Пики скорее не краткосрочные будут, а дневные колебания, которые в принципе будут выравнены, ввиду трёх мастеров с охватом всего шарика, тем самым, когда в америке будет ночь, будет писаться "пик" азиатского трафа

вот ни разу они у тебя выравнены не будут. днем один мастер захлебывается, ночью другой

А момент о том, что Мастера друг другу реплицируют ты учитываешь?

https://kafka.apache.org/

а как он влияет?

ты же не будешь из азии в америку гнать?

ты же не будешь из азии в америку гнать?

Кого? Юзера или репликацию?

запросы

или ты про "выравнены позиции репликации", а не "выравнена нагрузка"?

исходя из распределенности системы, у вас нет выбора. только очереди. или вы надеетесь на асинхронную репликацию, или даже думаете о синхронной?)

А про то, что мастера между собой будут иметь Master-Master Active-Active репликацию

Нет, синхронная репликация выбрысывается

исходя из распределенности системы, у вас нет выбора. только очереди. или вы надеетесь на асинхронную репликацию, или даже думаете о синхронной?)

почему распределенность системы подразумевает очереди?

ну опять-таки в случае очередей нет никакой нужды в master-master

А про то, что мастера между собой будут иметь Master-Master Active-Active репликацию

тогда я не понимаю то сообщение про пики нагрущки )

Зачем мне лишние прослойки? Это про очереди

ну опять-таки в случае очередей нет никакой нужды в master-master

да я думаю мускул и им подобные уже все-таки можно выбросить, не та задача

а причем тут это? формируем события на все кластеры, и пусть каждый пишет в БД себе по мере возможности. Никаких проблем с нагрузкой, никаких master-master, все надежно и предсказуемо

Угу пока в диск не уткнемся

тогда я не понимаю то сообщение про пики нагрущки )

Ну смотри, про пики начал ты. Меня не сильно волнуют пики, сервера должны стоять такие, чтобы переживать все пики, у меня всё достаточно быстро пишется, это не проблема. При желание можно разогнать MySQL/Percona до очень больших скоростей записи. Меня это совсем не напрягает до такой степени, чтобы думать, как подключить ещё лишние технологии и усложнить общую архиктетуру. А написал я про пики, что нету пиков таких, что вот 5 секунд всё ложится, как при ДДоС атаке, а потом 5 минут передышка, и есть время разобрать накопившиеся, там будет постоянная нагрузка, будут суточные калебания, наплывы и затишья. Но так как мы охватываем все континенты, то наплыву будут в разное время и тем самым, круглые сутки будет равномерно примерно одинаковая нагрузка.

я вот не в курсе там в mysql хотя бы Unlogged таблицы впилили ?

на постгресе при быстрых SSD и поминутной аггрегации входящего потока вполне можно было жить

а причем тут это? формируем события на все кластеры, и пусть каждый пишет в БД себе по мере возможности. Никаких проблем с нагрузкой, никаких master-master, все надежно и предсказуемо

И куда, и как часто это потом сливать?

ну я надеюсь, там нет по условиям mysql, он же ненадежен немножка. postgres удачнее подойдет