Спасибо Тони 2001 за интересный рассказ о Judy массивах, а так же за его
интересное и полезное расширение, которое хорошо подойдет для расчетных задач (статистика и биллинг).
Непременно буду иметь его ввиду. Сам хотел сделать нечто подобное ;), даже это обсуждалось на Хабре более года назад в одной из тем про структуры данных, но просто не было подходящего проекта под эту задачу.
Лично я собирался использовать judy массивы в своих сишных проектах, по этому немного в теме,
но в конечном итоге стал использовать dict (libdict) и tokyocabinet в силу их более понятного АПИ, а так же решаемому объему задач (мне более 100 M элементов не надо).
Мы, все расчетные задачи выносим в бэдграунд, которые реализованы как сишные демоны. Да и пользователей у нас 25М, а не 100+М как в Баду…
> $users = mysql_query('select * from badoo.users');
это будут данные только с одного шарда, который содержит около 100К записей.
так-что в этом случае можно обойтись и простым массивом.
Пользуюсь Теле-2 лет пять, нареканий нет, за исключением мелочей:
Иногда нет связи в гипермаркете (у МТС есть) и в области (Грузино) не берет в доме (МТС берет, а Мегафон и Билайн тоже нет)
Плачу значительно дешевле, чем МТС.
жаль, если эту сеть перекупят жадные корпоративные ублюдки… и все тарифы сведут в одну сетку
кто там еще не верит?
прошу сделать следующий эксперимент:
сделайте 10M INSERT посмотрите место,
потом 5M рандомных DELETE — посмотрите место,
потом еще 5M рандомных INSERT
и наконец 10M DELETE.
Eсли у вас будет размер файла близким к первоначальному, то это будет просто замечательно…
как раз у нас MyISAM и пухнет, и спасет лишь только backup/restore часов эдак на 100… а сервис останавливать нельзя ни на минуту иначе пользователи повернутся задом и мы останемся без хлеба :)
для меня главное — первое, работа должна приносить моральное удовлетворение от того, что ты делаешь…
ты строил дом? если нет — то жаль… очень приятно видеть и осязать плоды своего труда… И приятнее вдвойне, если эти плоды приносят какую-то пользу и ими пользуются многие…
посмотрел доклад баду, все почти в точности как и у нас…
да, мы тоже пошли по пути баду и сделали свой велосипед свое nosql решение, потому-что существующие не справлялись, с тем исключением, что взяли за основу TokyoCabinet.
В отличие от архитектуры решения баду — у нас есть минишардинг, т.е. мы шардим наши хештаблицы, т.е. не используем одну большую, а используем несколько средних в пределах одного демона.
Ну и у нас объемы в 10 раз меньше, чем в баду.
В хранилище держим счетчики симпатий (типа лайки), геоданные и еще какую-то муть… Производительность в продакшене 4.5К транзакций в сек. Реально — может выдержать больше процентов на 30.
Жаль, что нет опции «лучшее из избранного», а то, я бы добавил в такую папку.
Сам, как любитель писать разные статьи и на пол пути к изданию книги, во многом согласен с автором.
Есть процесс написания… научной фантастики, популярных статей, узко-специализированных публикаций или кода… и если этот процесс поставлен эффективно, то он подчиняется одинаковым принципам, которые диктует сама жизнь…
Как любитель фантастики и поклонник Стивена Кинга, восхищаюсь его книгой. Спасибо автору, за столь интересную аналогию.
там где есть объемы — идет борьба за ресурсы.
все что сберегает ресурсы — может нам помочь :)
так, что где есть нагрузка и объемы всегда найдет применение judy массивам
интересное и полезное расширение, которое хорошо подойдет для расчетных задач (статистика и биллинг).
Непременно буду иметь его ввиду. Сам хотел сделать нечто подобное ;), даже это обсуждалось на Хабре более года назад в одной из тем про структуры данных, но просто не было подходящего проекта под эту задачу.
Лично я собирался использовать judy массивы в своих сишных проектах, по этому немного в теме,
но в конечном итоге стал использовать dict (libdict) и tokyocabinet в силу их более понятного АПИ, а так же решаемому объему задач (мне более 100 M элементов не надо).
Мы, все расчетные задачи выносим в бэдграунд, которые реализованы как сишные демоны. Да и пользователей у нас 25М, а не 100+М как в Баду…
это будут данные только с одного шарда, который содержит около 100К записей.
так-что в этом случае можно обойтись и простым массивом.
judy массивы здесь могли бы существенно помочь.
— в городе появился — новый телеоператор
— какой?
— теле-3
— а что это за оператор?
— Теле-2 поставило третью вышку…
Иногда нет связи в гипермаркете (у МТС есть) и в области (Грузино) не берет в доме (МТС берет, а Мегафон и Билайн тоже нет)
Плачу значительно дешевле, чем МТС.
жаль, если эту сеть перекупят жадные корпоративные ублюдки… и все тарифы сведут в одну сетку
2) по какому критерию/алгоритму формируется значение параметра «score»
Спасибо Вам
— MySQL, PgSQL, MongoDb, NoSQL
прошу сделать следующий эксперимент:
сделайте 10M INSERT посмотрите место,
потом 5M рандомных DELETE — посмотрите место,
потом еще 5M рандомных INSERT
и наконец 10M DELETE.
Eсли у вас будет размер файла близким к первоначальному, то это будет просто замечательно…
ты строил дом? если нет — то жаль… очень приятно видеть и осязать плоды своего труда… И приятнее вдвойне, если эти плоды приносят какую-то пользу и ими пользуются многие…
да, мы тоже пошли по пути баду и сделали свой велосипед свое nosql решение, потому-что существующие не справлялись, с тем исключением, что взяли за основу TokyoCabinet.
В отличие от архитектуры решения баду — у нас есть минишардинг, т.е. мы шардим наши хештаблицы, т.е. не используем одну большую, а используем несколько средних в пределах одного демона.
Ну и у нас объемы в 10 раз меньше, чем в баду.
В хранилище держим счетчики симпатий (типа лайки), геоданные и еще какую-то муть… Производительность в продакшене 4.5К транзакций в сек. Реально — может выдержать больше процентов на 30.
подробнее
Сам, как любитель писать разные статьи и на пол пути к изданию книги, во многом согласен с автором.
Есть процесс написания… научной фантастики, популярных статей, узко-специализированных публикаций или кода… и если этот процесс поставлен эффективно, то он подчиняется одинаковым принципам, которые диктует сама жизнь…
Как любитель фантастики и поклонник Стивена Кинга, восхищаюсь его книгой. Спасибо автору, за столь интересную аналогию.