- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день,
Вопрос в первую очередь адресован профессионалам с опытом. Предположения в данном вопросе зачастую оказываются не верны.
Итак дано:
1. php скрипт куда валятся запросы с 60 000 gps приемников данные (60 к в минуту имеетя ввиду). Скрипт подключает adodb, распаршшивает пришедшую get или post строку и делает запись в 1 таблицу.
2. сервер линух, выделенный, средней паршивости (пару гиг оперативы, пару гигагерц проц, никаких райдов и прочего).
3. БД - postgre sql с модулем postgis.
Очевидно что при эмуляции такого числа запросов будут проблемы и все записи не попадут в БД. Конечно же нужна соответственная настройка. Например у апача по дефолту 256 воркеров - они тупо не успевают выполнять около 9 000 запросов в секунду. А также может и оперативка закончится и база лечь и т.п. т.п.
Собственно вопрос:
У кого есть опыт разработки\настройки подобных систем или их частей? Поделитесь опытом пожалуйста. С тем кто действительно в этом хорош хотелось бы поработать.
Советы нужны конкретные, например:
Первым делом настроить апач, поставить на него такие то модули. Разнести его на 4 сервера - 2 ведущих и 3 слэйва. Базу раскинуть на еще 3 сервера такой то мощности с такими то райдами.
Также хотелось бы пообщаться со специалистом по базам данных, который умеет горизонтально разносить данные. Путем несложного расчета можно определить что вышеописанная система пишет в базу 86 миллионов строк данных, храня которые в 1 таблице выборки по ней уже будет невозможно делать.
Первым делом настроить апач, поставить на него такие то модули. Разнести его на 4 сервера - 2 ведущих и 3 слэйва. Базу раскинуть на еще 3 сервера такой то мощности с такими то райдами.
Первым делом нужно выкинуть апач вообще.
Вторым делом нужно корректно спроектировать прием данных - очевидно, что узким местом системы будет именно бесконтрольно плодящиеся потоки php-процессов. Сделовательно, первый шаг оптимизации - сокращение времени на прием и сохранение данных. Минимум обработки, и максимально быстрое засовывание в хранилище - причем, не обязательно БД, вполне может быть и memcachedb, в котором организована очередь.
Впрочем, 60к в минуту - это всего 1к в сек., mysql вполне сносно умеет порядка 6-8 тыс. инсертов в секунду.
Также хотелось бы пообщаться со специалистом по базам данных, который умеет горизонтально разносить данные. Путем несложного расчета можно определить что вышеописанная система пишет в базу 86 миллионов строк данных, храня которые в 1 таблице выборки по ней уже будет невозможно делать.
Выборки по таблице в 200 млн строк при грамотно написаных индексах у меня на десктопе занимают порядка 2-3 сек.
Но если вы напрягаетесь по этому поводу - откройте для себя шардинг.
Первым делом нужно выкинуть апач вообще.
а на что же его поменять? :)
Вторым делом нужно корректно спроектировать прием данных - очевидно, что узким местом системы будет именно бесконтрольно плодящиеся потоки php-процессов. Сделовательно, первый шаг оптимизации - сокращение времени на прием и сохранение данных. Минимум обработки, и максимально быстрое засовывание в хранилище - причем, не обязательно БД, вполне может быть и memcachedb, в котором организована очередь.
У меня данные приходят в гет запросе, где двоеточием разделены столбцы (координата Х, координата У, высота, скорость, время). Пхп скрипт делает split и сразу инсерт.
Выборки по таблице в 200 млн строк при грамотно написаных индексах у меня на десктопе занимают порядка 2-3 сек.
Но если вы напрягаетесь по этому поводу - откройте для себя шардинг.
86 миллионов в сутки. а хотелось бы хотя бы месяц хранить.
Спасибо за содержательный ответ. Надеюсь на продолжение.
Первым делом нужно выкинуть апач вообще.
это весьма спорно. наоборот, если логики в постобработке скриптом
мало - можно и засунуть ее в модуль апача, например. + mpm worker использовать.
У меня данные приходят в гет запросе, где двоеточием разделены столбцы (координата Х, координата У, высота, скорость, время). Пхп скрипт делает split и сразу инсерт.
как раз ваш случай. нафиг здесь php не нужен.
а на что же его поменять? :)
nginx естественно.
У меня данные приходят в гет запросе, где двоеточием разделены столбцы (координата Х, координата У, высота, скорость, время). Пхп скрипт делает split и сразу инсерт.
Координаты в виде дробных градусов? ID записи имеется?
Но вобщем, в любом случае - время выполнения - копеечное.
86 миллионов в сутки. а хотелось бы хотя бы месяц хранить.
Ну, во-первых, у вас данные жестко структурированые, и незначительного объема - я бы на вашем месте сначала на кошках потренировался, есть неплохая вероятность, что пару-тройку млрд. строк база переварит, и не чихнет.
Во-вторых, вам действительно жизненно необходимо хранить сырые необработанные данные? Это может быть нелучшим вариантом.
Outsourcenow добавил 03.12.2009 в 19:51
это весьма спорно. наоборот, если логики в постобработке скриптом мало - можно и засунуть ее в модуль апача, например. + mpm worker использовать.
Идея скрещивать веб-сервер с sql - порочна в принципе.
Но вцелом, если так уж хочется - проще дописать плагин к nginx, как, собственно, многие и делают. Только от sql в качестве хранилища надо будет отказаться совершенно точно.
nginx естественно.
насколько я помню это ведь тоже апача проект? может ошибаюсь...
Координаты в виде дробных градусов? ID записи имеется?
Но вобщем, в любом случае - время выполнения - копеечное
координаты да. айди телефона с которого идут данные(не цифра а смесь цифр с буквами). в базе автоинкремент делается.
Ну, во-первых, у вас данные жестко структурированые, и незначительного объема - я бы на вашем месте сначала на кошках потренировался, есть неплохая вероятность, что пару-тройку млрд. строк база переварит, и не чихнет.
Во-вторых, вам действительно жизненно необходимо хранить сырые необработанные данные? Это может быть нелучшим вариантом.
попробовать можно. а данные именно такие и нужны. можно правда повыкидывать лишнее. по сути мне нужен айди телефона, время, и 2 координаты. Кстати тут еще ньюанс. я использую постгре с постгисом - координаты преобразую в геометрии и сую в базу.
П.с написал вам в асю.
насколько я помню это ведь тоже апача проект? может ошибаюсь...
Совсем нет. И в этом его преимущество.
попробовать можно. а данные именно такие и нужны. можно правда повыкидывать лишнее. по сути мне нужен айди телефона, время, и 2 координаты. Кстати тут еще ньюанс. я использую постгре с постгисом - координаты преобразую в геометрии и сую в базу.
Ну так просто нагенерите в табличку сотню миллионов рандомных записей, и проверьте.
Я смутно представляю себе, как работает постгис, но что-то мне подсказывает, что это плевая задача - учитывая всякие openstreetmaps.org.
П.с написал вам в асю.
Вылез, стукнтитесь еще раз, если не сложно.
1-й вариант с одним сервером.
На одном сервере php и mysql такую нагрузку возможно не выдержат.
Может вообще отказаться от веб сервера, от пхп, от mysql.
Написать на языке С программу, которая будет открывать TCP/IP сокет, принимать на него данные и записывать их в память или файл.
2-й вариант с несколькими серверами.
Сделать, что бы клиенты обращались не к одному серверу, а к одному из нескольких.
Распределить нагрузку на несколько серверов.
Написать на языке С программу, которая будет открывать TCP/IP сокет, принимать на него данные и записывать их в память или файл.
Самая здравая идея, кстати. Минус ровно один - времени на отладку многопоточного самодельного демона уйдет - вагон.
Идея скрещивать веб-сервер с sql - порочна в принципе.
"звучит умно" (с)
что вы хотели этим сказать, если не сложно?
Но вцелом, если так уж хочется - проще дописать плагин к nginx, как, собственно, многие и делают. Только от sql в качестве хранилища надо будет отказаться совершенно точно.
многие точно также используют апач. тем более, что там давно уже есть
mod_dbd, использовать который в своем модуле никто не мешает.
nginx просто моден, ну какие приемущества дает его модель
работы в качестве бакенда?
насколько я помню это ведь тоже апача проект? может ошибаюсь...
ходят слухи, что оно когда-то давно было его форком. но от апача там мало чего осталось.
в апаче есть аналогичный nginx-у mpm модуль (event), неплохо работает на проксировании.
Самая здравая идея, кстати. Минус ровно один - времени на отладку многопоточного самодельного демона уйдет - вагон.
ну и что мешает использовать тот самый апач в качестве демона? он ведь
конструктор по сути. только большинство работы за нас уже
сделали (mpm, модули для работы с БД ...)
1-й вариант с одним сервером.
На одном сервере php и mysql такую нагрузку возможно не выдержат.
Может вообще отказаться от веб сервера, от пхп, от mysql.
Написать на языке С программу, которая будет открывать TCP/IP сокет, принимать на него данные и записывать их в память или файл.
2-й вариант с несколькими серверами.
Сделать, что бы клиенты обращались не к одному серверу, а к одному из нескольких.
Распределить нагрузку на несколько серверов.
скорее вариант 3. ведь кроме приемщика данных есть еще и сайт который их использует наряду с другими данными.
1 сервер сайт.
2 сервер приемщик
3 сервер база
А по конфигурации сервера кто нибудь что нибудь посоветует? райды, оперативы, процессоры и т.п. Что лучше для производительности\стабильности?