|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день,
Нужен совет по задаче.
Есть около 240 000 000 inserts за сутки. Это координаты точки на карте. Тип поля POINT (в таблице есть еще три поля). Не предполагается ни Update ни Delete. Partitioning по часам включен, шардинг таблицы есть. соотнощение: Select будет проходить 1 к 100 Inserts
Вопрос.
1. Стоит ли рассмотреть в качестве варианта MongoDB или CouchDB, будет ли это эффективно.
2. MyISAM потянет ли такие нагрузки?
3. Имеет ли смылсл делать bulk inserts?
4. Как лучше оптимизировать конфиги под такую задачу?
Спасибо большое.
Неактивен
Добрый день.
Интересная у Вас задачка, около 3к вставок в секунду 
1. По поводу производительности MongoDB vs CouchDB vs MySQL я, наверное,
ничего не скажу — это все-таки разные сущности. В любом случае, Вам нужно
будет делать шардирование, особенно, если есть какие-то индексы. Причем
не по времени, а по какому-то другому признаку (так, чтобы одновременно
работало несколько шардов).
2. Потянет так же, как и любой другой сторадж — при условии достаточного
количества шардов. Сколько конкретно вставок он выдержит — зависит от ко-
личества индексов, размера данных и т.д. По хорошему — надо написать
сценарии, которые подолбят в MySQL и в Mongo, и определить пиковые зна-
чения RPS.
3. В случае с MyISAM — да, имеет. В этом случае индексы будут строиться
несколько быстрее.
4. Опять же в случае с MyISAM — смотрите на размеры key_buffer_size и
sort_buffer_size — их размеры напрямую влияют на скорость перестройки
индексов при добавлении. Учтите, что sort_buffer — это значение на поток,
а не на сервер глобально.
Неактивен
Спаисбо.
да, около 3000 в секунду, примерено 1000 объектов заносят свои координаты ежесекундно + есть смежные.
Разобрался. Разбил таблицы еще сильнее по доп. индексу и разнес шардинг.
По MongoDB и CouchDB - не известно сколько пиково они могут принять? ограничено винтом? и сколько времени возмет перестройка индексов. Хотя конечно в MongoDB и CouchDB они работаю по-разному, и Couch 1.0 работает более оптимально. Буду писать benchmarks.
по пункту 4 сортировка мне наверное вообще не нужна. Выборка будет только суммарное расстояние от определенной точки для одного объекта за сутки. А возможно имеет смысл пересчитывать его налету, скажем каждые 10 инсертов.
Неактивен
Couchа я боюсь: он написан на erlang. Если вдруг что-то случится с данными,
их даже прочитать никак нельзя будет — найти человека, который разберется
с функциональным языком, куда сложнее, чем простого плюсатого программиста.
Что касается Mongo — она, вроде, работает достаточно быстро *до* флаша на
диск. Т.е. она сама по себе старается просто mmapить файлик в память, но
иногда с ней что-то происходит, и она начинает усиленно писать на диск, при
этом не обрабатывая соединения. Честно говоря, не знаю, с чем это связано 
Так что бенчмарки сделайте продолжительные — хотя бы с час.
Если Вам нужно из данных только одно число, то имеет смысл хранить только
это число, а остальные данные выбрасывать 
Неактивен
Mongo в продакшн еще очень не скоро можно будет.
Если вообще допилят
http://www.google.ru/#q=mongodb+segment … 58965fcd35
Неактивен
Ничего не знаю, 1.4 работает нормально
Неактивен
