За последние 24 часа нас посетили 62108 программистов и 1781 робот. Сейчас ищут 813 программистов ...

Обработка больших массивов данных.

Тема в разделе "Прочие вопросы по PHP", создана пользователем RomanBush, 29 янв 2008.

  1. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    Есть задача.
    Из нескольких источников идёт поток информации. Большой поток. Если нарисовать таблицей, то получится - 15-20 полей, каждое от 50 до 150 символов. Но таких записей будет около 30-50 тысяч в сутки.
    Всю эту инфу надо хранить минимум год и иметь возможность стоить различные отчёты за весь период. Отчёты будут формироваться из нескольких полей (никогда - из всех).
    При этом хочется ограничиться рамками php+mysql.

    Кто-нибудь знает, как такие вещи реализовываются? Или где почитать про реализацию таких вещей?
    Не скажу, что я совсем не знаю, как такие задачи решать, но хочу услышать ещё одно мнение. Лично я вижу 5 решений.
     
  2. Anonymous

    Anonymous Guest

    На оракле ^_^. Шутка.
     
  3. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    > Лично я вижу 5 решений.

    рассказывай :)
     
  4. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    Гы. Так я и хотел услышать ещё решения. А заодно проверить, правильно ли я придумал решения.

    Вообще-то это одно из пяти решений, которое мне пришло в голову. Только засада в том, что я не знаю оракла. Поэтому и написал, что хотелось бы обойтись связкой php+mysql.
     
  5. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    > Так я и хотел услышать ещё решения.

    чтобы услышать ещё надо огласить уже.
     
  6. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
     
  7. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    те решения, что тут не огласят, ты будешь считать неправильными?
     
  8. Anonymous

    Anonymous Guest

    Ну, у нас на оракле ^_^
     
  9. DarkElf

    DarkElf Активный пользователь

    С нами с:
    22 окт 2006
    Сообщения:
    1.632
    Симпатии:
    0
    имхо, все зависит от кол-ва просмотров статистики и бюджета на оптимизацию и кластер серверов:)
     
  10. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    20 миллионов записей в год. Ну это не на столько страшно, если это внутреняя система, которой не кричитна скорость +- 0.5 секунды. MySQL вполне справится. Сайт в подписи (по работе который) - там данных ещё больше и крайне интерактивная система - нормально справляется. Только юзать надо InnoDB.
    А дальше уже какие-то конкретные оптимизации в зависимости от задач типа прегенерации отчётов, дополнительных служебных таблиц и.т.д.
     
  11. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    А можно чуть поподробнее - почему?

    Пиковая загрузка ожидается 100 юзеров. Средняя - 20-50. Потянет?

    И ещё вопрос - а класть лучше в одну таблицу или постараться разпределить по нескольким, "по смыслу"?

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

    имеется в виду, для хранения промежуточно посчитанных данных или ещё что-то?
     
  12. armadillo

    armadillo Активный пользователь

    С нами с:
    6 апр 2007
    Сообщения:
    2.380
    Симпатии:
    0
    Адрес:
    Russia, Moscow
    http://php.ru/forum/viewtopic.php?p=79868#79868

    Структура - просто оптимизировать по скорости, надо смотреть какие отчеты.
    Это зависит от того чем они будут заняты. 100 человек будут непрерывно смотреть разные отчеты по 20 млн записям?

    опять же это зависит от логики отчетов и логики их использования.

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

    В общем дальнейшие вопросы уже не на абстрактном уровне обсуждаются.
     
  13. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    В приковые моменты - почти так. Например, в конце года всем интересна динамика изменения показателей за год. Врятли, конечно, они все одновременно усядутся это делать, но общее кол-во юзеров >1000, так что нельзя исключать, что и 100 чел будут одновременно это делать. Правда, это можно обозвать "форс-мажором" и послать всех в жопу - кому надо - подождут. А если не срочно - попозже зайдут/посмотрят.

    Ок. А есть что-нибудь почитать? Ссылкой кинетесь? Хочу всё-таки сначала по максимуму рассмотреть задачу на абстрактном уровне. Дабы знать возможные варианты подходов к решению таких задач.

    Кста, вот это - действительно ответ на вопрос - что выбрать myisam или innodb:
    http://www.mysqlperformanceblog.com/200 ... ks-part-1/
    Хотя и называется "InnoDB vs MyISAM vs Falcon benchmarks"
     
  14. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    Тут FULLTEXT, там транкзации. Однозначно на вопрос не ответить.
     
  15. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    в моём случае - это ответ. fulltext мне врятли понадобится.
     
  16. Anonymous

    Anonymous Guest

    Поэтому то оракл и рулит ^_^ и фуллтехт, и транзакции )))
    У нас кешируются все ежемесячные и годовые отчеты, значение которых в дальнейшем не изменяется. Генерируются по первому требованию и лежат потом в файловом кеше или снепшотам в базе. После перехода на статичные отчеты нагрузка на сервер упала на порядок.
     
  17. RomanBush

    RomanBush Активный пользователь

    С нами с:
    5 дек 2007
    Сообщения:
    798
    Симпатии:
    0
    Адрес:
    200 км от Москвы
    Спасибо. Хорошая мысль.