На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2006-1-20 на главную / новости от 2006-1-20
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 20 января 2006 г.

Google внедряет открытые стандарты IM

Пользователи Google Talk получили возможность устанавливать связь с другими службами интернет-пейджинга, поддерживающими протокол XMPP.

Google внесла свой вклад в открытие мира интернет-пейджинга, сделав свою службу Google Talk взаимодействующей с другими IM-службами, которые используют Extensible Messaging and Presence Protocol (XMPP). Это открытый протокол XML — его иногда еще называют протоколом Jabber, — применяемый для обмена данными в режиме реального времени между двумя точками в интернете. Он используется многими IM-приложениями с открытым исходным кодом, включая JabberNow и Earthlink.

Обеспечив поддержку XMPP на уровне серверов, Google предоставляет пользователям Talk возможность общаться с другими IM-службами, поддерживающими XMPP сервер-сервер. В заявлении Google говорится, что она, «как всегда, старается предоставить пользователям выбор и опирается на открытые стандарты».

Служба Google Talk работает с прошлого года. Сначала она использовала XMPP только в качестве протокола клиент-сервер, что позволяло подключаться к системе через разные клиенты, но члены сообщества Google Talkers не могли применять приложение для связи с пользователями других IM-сетей.

Сейчас три крупнейших оператора интернет-пейджеров — Microsoft, Yahoo и AOL — сохраняют свои сети закрытыми и не поддерживают XMPP сервер-сервер. Три фирмы вели переговоры о расширении взаимодействия, но пока тем, кто хочет объединить контакты из разных IM-служб, приходится прибегать к помощи таких посредников, как Trillian, Gaim или Adium.

Google поддерживает усилия по обеспечению полного, открытого взаимодействия, которое она называет федерацией. «Электронная почта служит примером федеративной сети, которая позволяет людям общаться друг с другом, независимо от того, услугами какого поставщика email они пользуются. Открытое взаимодействие — это первый шаг на пути к достижению аналогичного уровня открытости и возможностей выбора для пользователей служб интернет-пейджинга и VoIP. И благодаря сегодняшнему введению в строй федерации сервер-сервер, Google Talk позволяет миллионам людей во всем мире общаться друг с другом в режиме реального времени», — говорится в заявлении Google.

Согласно информации с веб-сайта Google, компания планирует также поддержать SIP — протокол, лежащий в основе VoIP. 

 Предыдущие публикации:
2005-08-24   Google вышла на рынок IM
 В продолжение темы:
2006-01-30   Google обновляет Toolbar
2006-02-21   AOL предложит платный интернет-пейджинг
2006-07-15   Microsoft и Yahoo соединили свои IM-службы
Обсуждение и комментарии
vIv - viv.justgmail.com
20 Jan 2006 5:35 PM
Гугль захватывает мир :-)
 

M&M's
20 Jan 2006 6:40 PM
> Электронная почта служит примером федеративной сети, которая позволяет людям общаться друг с другом, независимо от того, услугами какого поставщика email они пользуются

А также получать горы спама, потому как открытый емайл не утаишь.
 

vIv - viv.justgmail.com
20 Jan 2006 7:00 PM
тех, у кого GMail проблемы спама не трогают :-)
 

vIv - viv.justgmail.com
20 Jan 2006 7:11 PM
кстати, никто не слышал, как бы МХ на GMail завернуть? :-)
 

M&M's
20 Jan 2006 8:52 PM
2 vlv:
> тех, у кого GMail проблемы спама не трогают :-)
Вы это серьезно? Неужели Гугл договорился со спамерами? Надолго ли?
 

vIv - viv.justgmail.com
20 Jan 2006 9:36 PM
Могу дать пригласилку - проверишь сам :-)
При их обьёмах работает принцип: чем больше спамят на гугль (всем юзерам) тем точнее работают фильтры. Может, они свой поиск сюда привернули как-то, может ещё что, но факт остаётся фактом: спама мне валится море, но он очень точно детектируется именно как спам
 

talk.google.com
20 Jan 2006 9:37 PM
>> Гугль захватывает мир :-)

# Australia
# Indonesia
# Malaysia
# New Zealand
# The Phillipines
# Singapore
# Thailand
# Turkey
# United States

only
 

fi
20 Jan 2006 9:57 PM
Что и говорить, хорошая вещь google ;)
 

vlv
21 Jan 2006 12:47 AM
>спама мне валится море, но он очень точно детектируется именно как спам

представляешь у меня spamassasin тоже очень точно выфильтровывал спам и всего то в пределах моих скромных усилиях над одним единственным ящиком.

а если тренировать фильтры на тысячах ящиков то не удивительно

и ничего технически нового там нет.

зато как они SIP очень хитро прикрутили это явно прогресс
 

Ender
21 Jan 2006 8:37 AM
2M&Ms: Пользуюсь gmail где-то с весны-начала лета. За все это время во "входящие" ошибочно попало 2..3 письма со спамом, остальные благополучно попадают в соответствующую папочку "Спам". Один раз нужное письмо попало в "Спам" (адресат не был в списке доверенных лиц), хотя после анализа текста, вынужден был признать что письмо было очень похоже на спам.
 

M&M's
21 Jan 2006 4:32 PM
2 vlv:
у меня есть ящик на GMail, только вот не заглядывал в него уже плгода... Вообще этих ящиков у меня и на МСНе, и на Гугле, и везде, хоть отдавай кому попало, за всеми не уследишь...
 

M&M's
21 Jan 2006 4:35 PM
Причем у всех какой-то подозрительно стандартный функционал, прям даже неловко как-то за почтовые службы, неужто капельки мозгов не хотят применить для расширения функциональных возможностей почты, а то - входящие, исходящие, удаленные и спам - и все. Никакога разноарбузия.
 

M&M's
21 Jan 2006 4:42 PM
Вообще достаточно вставить фильтр на фразу "Данное письмо не является спамом...", и половина всего спама сразу будет уходить в корзину :-))
Однако все эти фильтры - не идеальное решение, нужные письма в спам тоже попадают, а сам спам - достаточно спамерам нанять одного-двух редакторов-стилистов, и почтовые фильтры будут сосать, а юзвери - исправно получать красивый, разнообразный, грамотно оформленный в стиле лучших мировых классиков спам :-))
 

Anti-MS
22 Jan 2006 11:47 AM
M&M's

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

M&M's
22 Jan 2006 2:50 PM
2 Anti-MS:
Может объясните, что есть "новые виды спама" и насколько часто в сети они появляются? Как я понимаю, появляются каждый день. Достаточно одной массовой рассылки на адрес "undisclosed recipients", чтобы завалить спамом пол-рунета. Другая рассылка - это уже другая история и другой спам.
Конечно не имеются в виду отмороженные MLM рассылки от онлайновых барыг, которых блокировать легко раз и навсегда, так как они даже ленятся менять текст нисходящих сверху рассылок.
 

Shamlo - shamlonarod.ru
23 Jan 2006 11:58 AM
Любой спам можно отфильтровать. Если не полностью автоматически, то как минимум полуавтоматически. Например, если одно и то же письмо отправлено на 1000 адресов, а первые 50 получателей открыли его и нажали на кнопку "Спам", то у остальных 950-ти письмо смело можно переносить в папку для спама. Подозреваю, что ГМайл так и работает.
 

M&M's
23 Jan 2006 2:33 PM
2 Shamlo:
разовые рассылки отправляются одновременно на миллионы адресов. Никакой юзер в миллионные доли секунды не успеет отреагировать со своей кнопкой
 

Лось
23 Jan 2006 3:20 PM
2 M&M's
подумай сам - причем тут "одновременно" и "отреагировать в доли секунды"? Пришел миллиону адресов "новый" спам. Честно попал в папку "входящие". Первые 50 прочитавших его и нажавших заветную кнопку (совершенно неважно за какой период времени) дают сигнал Гуглю выполнить разовую операцию переброски данного письма у остальных 999 950 ящиков из "входящих" в "спам". Эти юзеры (за исключением первых 50) даже и не догадаются, что это письмо успело побывать у них во "входящих".
Уверен, что для разовой массовой смены папки любого письма в любом кол-ве ящиков, технических препятствий у Гугля не существует.
 

00alex
23 Jan 2006 4:23 PM
2Лось:
Если бы так работали спам фильтры, то никакой бы мощности компьютеров не хватило на борьбу со СПАМОМ в текущем объеме... "дать команду перекинуть одно письмо в миллионе ящиков"... это ж надо...
 

Shamlo - shamlonarod.ru
23 Jan 2006 4:42 PM
> 00alex: Если бы так работали спам фильтры, то никакой бы
> мощности компьютеров не хватило на борьбу со СПАМОМ в текущем
> объеме...

Возможно, но только в том случае, если бы их надо было реально перекладывать. Очевидно, что Гугл хранит письма не в Unix-mailbox, а в SQL-базе. Поэтому для перекладывания в другую папку ему надо просто изменить одно поле. Массовый UPDATE на миллионы записей вряд ли займет больше нескольких секунд.
 

Crazy Frog - crazyfrog.ru
23 Jan 2006 5:14 PM
>Массовый UPDATE на миллионы записей
>вряд ли займет больше нескольких секунд.

Сразу становится понятно, что с "SQL-базами" вы не работали...
 

Shamlo - shamlonarod.ru
23 Jan 2006 6:35 PM
> Сразу становится понятно, что с "SQL-базами" вы не работали...

Откройте мне глаза!
 

Tolik
24 Jan 2006 7:24 AM
2 Shamlo

> Откройте мне глаза!

тебе ?
ох, сложно ...

>Очевидно, что Гугл хранит письма не в Unix-mailbox, а в SQL-
>базе

Откуда очевидно? Совсем не очевидно. Хотя может быть

>Массовый UPDATE на миллионы записей
>вряд ли займет больше нескольких секунд.

Есть такие глупые слова - транзакции (и их журнал), блокировки (или создание версий). Все они не очень дружат с понятием "Массовый UPDATE на миллионы записей " в многопользовательском окружении. Это тебе не концептуальные модели создавать.

На пустой и довольно мощной системе - да, но поставив её под 100% загрузки. При десятках тысяч активных коннектов - ой нехорошо будет ...

А еще многие юзеры уже увидели письмо во входящих. Опс ... - а оно куда-то пропало. Само. Нехорошо так юзера пугать-то
 

Сергей Павлович - grayman2000prokuratura.ru
24 Jan 2006 7:53 AM
Использую gmail с мая месяца. Доволен.
Главных недостатков, не считая мелких ляпов при переводе, нашел всего два:
1. Из русского интерфейса недоступны некоторые второстепенные возможности, доступные из англиского
2. При составлении письма в rich-text-e не работает PASTE.

2:vlv
> представляешь у меня spamassasin тоже очень точно
> выфильтровывал спам
Гм... для этого он сначала должен был получить текст этого письма. Здесь же фильтрация идет на стороне почтового сервера.

Да, на mail.ru тоже есть подобная фишка, но у меня в корзине там лежит уже под сотню писем от nbcindia, msatlas и тому подобное, где за индийские рупии предлагают покупать всевозможный софт.
Вся эта сотня оказалась в корзине после нажатия "пожаловаться на спам". Я не верю, что никому из (скольки?) тысяч пользователей mail.ru не приходили подобные предложения и никто не "жаловался".

Зато этот же спамодав на м.ру угробил мою подписку на одну из рассылок по TopSpeed Clarion и по нескольку раз на дню баунсил безобидные и нужные мне рассылки от yahoo, так что каждый день приходилось лезть на сайт и разблокировать отправку почты на этот адрес.
Перенес все рассылки на gmail и доволен жизнью - никаких напрасных баунсов.

Ну и последнее. Все-таки гугль держит свое слово по части "никаких баннеров, только текст и текстовые ссылки". Соответственно экономится траффик. (только не надо мне петь про баннерорезки, я и сам про них неплохо знаю)
 

vIv - viv.justgmail.com
24 Jan 2006 1:03 PM
А, кстати. вчера я и видел ИМЕННО ЭТО!
СПАМ-письмо приехало по РОР3, я его заметил и полез "нажимать кнопочку", - и за эти пару минут оно уже успело переехать в SPAM
 

Shamlo - shamlonarod.ru
24 Jan 2006 1:22 PM
> Tolik: На пустой и довольно мощной системе - да, но поставив
> её под 100% загрузки. При десятках тысяч активных коннектов -
> ой нехорошо будет ...

Так коннекты-то не к сиквелу, а к веб-серверу. А к сиквелу может быть идет один толстый коннект, по которому в одну сторону единым последовательным потоком летают тексты писем, а в другую - инструкции о том, где и что надо в базе изменить. Причем второй поток не менее последователен.

> А еще многие юзеры уже увидели письмо во входящих. Опс ... - а
> оно куда-то пропало. Само. Нехорошо так юзера пугать-то

Ну это совсем просто. У тех, кто уже увидел письмо, его можно не трогать. Статус письма Read/Unread - это всего лишь еще одно поле в записи. Если по этому полю есть индекс, то можно мгновенно исключить из рассмотрения письма, имеющие статус Read.
 

Tolik
24 Jan 2006 3:33 PM
Мда, с БД ты и правда не работал

>А к сиквелу может быть идет один толстый коннект, по которому
>в одну сторону единым последовательным потоком летают тексты
>писем, а в другую - инструкции о том, где и что надо в базе
>изменить.

Мягко скажем - неэффективная схема. Конечно, каждой сессии свой коннект не нужен, нужен их пул, но чтобы всех в один ... Да при таких объемах данных ... Просто на пальцах прикинь количество запросов к БД в секунду. И время на один запрос. А тут UPDATE на миллионы записей ... А остальные ждут ... ой, нехорошо ...

Ну опять лезешь в область в которой ни сном, ни духом. Ну ведь сразу видно, с СУБД под сколько-либо приличной нагрузкой никогда не работал.

>Статус письма Read/Unread - это всего лишь еще одно поле в
>записи.

... которое ОЧЕНЬ интенсивно UPDATE-ится
По каждому письму, каждым пользователем, многие сотни UPDATE в секунду могут быть ...

>Если по этому полю есть индекс, то можно мгновенно исключить
>из рассмотрения письма, имеющие статус Read

Ага, теперь по полю с такой интенсивностью UPDATE сделай SELECT, по таблице на миллионы (ох, не миллионы, ох сотни миллионов) записей, а я посмотрю на мгновенность выборки :-)))
 

Tolik
24 Jan 2006 3:40 PM
К слову сказать - статус Read - не катит

Он его только в списке писем увидел, еще не Read
Обновляет список - а оно пропало. Нехорошо. Не юзабельно
 

Shamlo - shamlonarod.ru
24 Jan 2006 6:17 PM
> Tolik: Мягко скажем - неэффективная схема.

Только если ее будешь реализовывать ты, руководствуясь вот этим вот моим абстрактным описанием, которое не претендует ни на что большее, чем просто обозначить идею. Видимо, твой уровень - это конкретное ТЗ, где уже все расписано в мельчайших деталях. Я просто не вижу другого объяснения тому, что ты так на них зациклен.

Обрати внимание на слова "может быть". Наличие этих слов означает, что коннект может быть один, а может и не быть. Может, например, быть по одному коннекту к каждому серверу СУБД. А может быть по два или три коннекта на сервер. Сами сервера могут быть построены в ветвистую иерархию с автоматической репликацией. Разные команды на изменение содержимого БД могут иметь различный приоритет. Например, перекладывания из папки в папку (особенно массовые) могут иметь приоритет много ниже, чем интерактивные операции, инициируемые клиентами. Может быть еще более навороченная система вроде какого-нибудь интеллектуального планировщика. Я же ведь нигде не сказал, что сервер всего один, и, что операции формируются и выполняются в одной и той же последовательности. Это ты сам додумал в своем больном воображении, а потом на меня показываешь и упрекаешь в неэффективности системы.

> Ну опять лезешь в область в которой ни сном, ни духом.
> Ну ведь сразу видно, с СУБД под сколько-либо приличной
> нагрузкой никогда не работал.

Но зато какой вывод. Сразу с плеча :)

> ... которое ОЧЕНЬ интенсивно UPDATE-ится
> По каждому письму, каждым пользователем, многие сотни UPDATE в
> секунду могут быть ...

Это вообще какая-то чушь. С чего вдруг все пользователи разом начнут апдейтить какое-то одно письмо.

> Он его только в списке писем увидел, еще не Read
> Обновляет список - а оно пропало. Нехорошо. Не юзабельно

Невапрос. Можно завести статус Seen/Unseen.
 

Сергей Павлович - grayman2000prokuratura.ru
25 Jan 2006 6:24 AM
Господа, такое ощущение, что все уже забыли про сколько-то тысяч (или сотен тысяч?) серверов в кластерах гугля. Уверен, что и "миллионы select/update в секунду" эта махина потянет без проблем. Лишь бы всё нормально работало.
 

Tolik
25 Jan 2006 6:39 AM
Ох, развесистый ты наш ...
Растекся опять мыслью по древу ...

Ну расскажи тогда как в ветвистой иерархии с автоматической репликацией случится мгновенный update миллионов записей ...
За несколько секунд ...

Какой SQL сервер имеет транзакции разного приоритета и как ты себе данный механизм без нарушения ACID представляешь? ....

>> Ну опять лезешь в область в которой ни сном, ни духом.
>> Ну ведь сразу видно, с СУБД под сколько-либо приличной
>> нагрузкой никогда не работал.

>Но зато какой вывод. Сразу с плеча :)

Да в общем-то вывод очевидный. Можешь опровергнуть ?
Какая система, где, какую роль в разработке или администрировании ты играл? Тут-то всё просто, называешь систему, которую тебе приходилось разрабатывать с точки зрения архитектуры БД и оптимизации её работы, примерные параметры (размер БД, количество активных юзерей и транзакций в секунду) и я извиняюсь, что зря обидел уважаемого человека.

Делов то ...
 

Tolik
25 Jan 2006 10:52 AM
2 Сергей Павлович

Кластер в OLTP системе дело не до конца очевидное. Ибо, если он shared Disk - то остается узкое место в виде дисковой системы и когерентности кэшей, а если Shared Nothing - то обслуживать такое на сотнях узлов - не в меру сексуально.

Да и на том же TPC.org в TPC-C задачах на сейчас максимум таки вынимается из некластерных систем.

Вобще же почта - не очень хороший объект для OLPT
SQL не сильно дружит с объектами, достигающими мегабайт и больше. Выкручиваться, конечно, можно, но всё это не даром идет.

так что почтовики на SQL-серверах не особо и делают. тут лучше специализированный софт для хранения.
 

Shamlo - shamlonarod.ru
25 Jan 2006 11:39 AM
> Tolik: Ну расскажи тогда как в ветвистой иерархии с
> автоматической репликацией случится мгновенный update
> миллионов записей ...

А кто говорил, что он будет мгновенным? Я тебе еще раз говорю, что все самое невероятное ты додумываешь сам, а объяснение почему-то требуешь с меня. Ты это придумал - ты и рассказывай как оно будет устроено.

> Какой SQL сервер имеет транзакции разного приоритета

Я вообще-то говорил не про транзакции, а про операции. Операции - это то, что впоследствии порождает соответствующие транзакции. Этим операциям на уровне бизнес-логики спокойно можно назначить такие приоритеты, чтобы они выполнялись (превращаясь в транзакции) в последовательности отличной от той, в которой они вставали в очередь на обработку.

> Да в общем-то вывод очевидный. Можешь опровергнуть ?

Зачем мне это? Почему ты так уверен в том, что все тебе что-то должны? В частности, с чего вдруг я должен тебе что-то доказывать? Ведь твое мнение абсолютно ни на что не влияет. Вот, например, если я сейчас назову тебя психически нездоровым, разве побежишь ты в псих-диспансер за справкой о том, что не состоишь у них на учете? Думаю, что нет. Так почему же ждешь от меня того, что я буду напрягаться, доказывая тебе что-либо?

Чтобы ты вдруг не подумал, что я ухожу от ответа, могу для удовлетворения твоего любопытства и в порядке лирического отступления привести некоторые факты. В свое время я лично разработал (сейчас просто поддерживаю) некий модуль для торговой системы. Максимальная скорость его работы была и остается 30-40 сделок в секунду (не в минуту). Причем каждая сделка, хотя и представляет собой одну транзакцию, сама по себе состоит из десятков SQL-операций, выполняемых над различнымими таблицами. Конечно, такие скорости на самом деле не нужны, так как реальная торговая активность много ниже. Однако тесты показывают, что даже при такой активности система будет работать. И это на простом двух-процессорном сервере, а не на кластере из тысяч машин.
 

Tolik
25 Jan 2006 12:13 PM
>Максимальная скорость его работы была и остается 30-40 сделок
>в секунду (не в минуту).
>Конечно, такие скорости на самом деле не нужны, так как
>реальная торговая активность много ниже

Что, собственно, и требовалось доказать. 40 транзакций в секунду пиковой производительности - это, звиняйте, курсовая для студента.

>чтобы они выполнялись (превращаясь в транзакции) в
>последовательности отличной от той, в которой они вставали в
>очередь на обработку.

Тогда твой милионный UPDATE не пойдет в работу никогда. Там не 40 транзакций в секунду, там их чутку больше. Думаю порядка на 3 как минимум.

>А кто говорил, что он будет мгновенным?

Не поверишь - ты

"Массовый UPDATE на миллионы записей вряд ли займет больше нескольких секунд"

 

Сергей Павлович - grayman2000prokuratura.ru
25 Jan 2006 12:37 PM
2 Tolik: "Заметьте, не я это предложил!" (С)
Не я говорил об SQL, я просто напомнил о гигантских вычислительных мощностях гугла...
 

Tolik
25 Jan 2006 12:45 PM
:-)))

Против гигантских вычислительных мощностей не возражаю.
Тем более стот это сейчас копейки, по большому счету.

Но сдуру можно любые мощности положить ...
 

Shamlo - shamlonarod.ru
25 Jan 2006 1:29 PM
> Tolik: Что, собственно, и требовалось доказать. 40 транзакций
> в секунду пиковой производительности - это, звиняйте, курсовая
> для студента.

Нет, ты не понял. Транзакция - это далеко не всегда одна операция с БД. Я говорю о транзакциях, каждая из которых включает в себя столько всего, что только в лог пишется по 10-15 килобайт текста, который лишь вкратце описывает случившиеся в системе события.

>> А кто говорил, что он будет мгновенным?
> Не поверишь - ты
> "Массовый UPDATE на миллионы записей вряд ли займет больше
> нескольких секунд"

И где здесь слово "мгновенно"? Или где здесь сказано, что это произойдет сразу как только? Может быть операция будет отложена до того времени, когда нагрузка спадет. Еще раз (третий) тебе говорю, что ты многое из того, что не сказано явно, додумываешь сам. Причем додумываешь самым неправильным образом :)
 

Tolik
25 Jan 2006 1:34 PM
2 Shamlo

>Нет, ты не понял

Я всё понял
40 SQL выражений в секунду это вообще не предмет для разговора.

>И где здесь слово "мгновенно

Хорошо, оставим слово "через несколько секунд"

Нагрузка на gmail спадет только по факту прекращения её действия. Никак не раньше :-)
 

Shamlo - shamlonarod.ru
25 Jan 2006 1:56 PM
> Tolik: Я всё понял
> 40 SQL выражений в секунду это вообще не предмет для
> разговора.

Транзакция != SQL-выражение. Кроме того, SQL-выражения бывают разные... очень разные. В том числе и такие, которых 40 штук за секунду не сможет выполнить ни один сервер.

> Нагрузка на gmail спадет только по факту прекращения её
> действия. Никак не раньше :-)

Если до нуля, то да. А если нужно, чтобы она просто перестала быть 100%-ой, то это произойдет раньше.
 

xacid
25 Jan 2006 10:57 PM
скорее всего всё несколько проще - для каждого письма вычисляется сигнатура (хэш) и ведется статистика сигнатур - если количество одинаковых сигнатур превышает некий порог то с вероятностью близкой к 1 это будет спам который смело можно роутить в соответсвующую папку
а для легальных рассылок просто ведем список исключений адресов отправителей и плюс еще некие опознавательные признаки ( в теме например )
посему можно сделать вывод сразу - спамерам теперь одна дорога - имитировать и мимикрировать под легал какой нибудь...
 

xacid
25 Jan 2006 11:00 PM
а хэш строить можно отфильтровав слова по базе "кодовых" слов (типа "виагра" и тд и тп)
как обычно и работают фильтры насколько я понимаю
 

Лось
26 Jan 2006 12:40 PM
Можно конечно долго спорить об оптимизации SQL-запросов (хотя кто сказал, что Гугль использует именно реляционную БД?), но ведь написал же человек, что он видел прыжок письма в спам СВОИМИ ГЛАЗАМИ:

>24 января, 2006, 13:03 - vIv
>А, кстати. вчера я и видел ИМЕННО ЭТО!
>СПАМ-письмо приехало по РОР3, я его заметил и полез "нажимать >кнопочку", - и за эти пару минут оно уже успело переехать в >SPAM

И вроде пока никто на быстродействие ГМэйл-а не жаловался :)
Кроме того, учитывая историческое наличие у Гугля научных наработок, связанных с искус. интеллектом, помноженное на нехилые вычислительные мощности, можно себе представить уровень "интеллектуальности" их фильтров... То есть многие миллионы спам-писем, вероятно, вообще не доходят до ящиков.
 

Shamlo - shamlonarod.ru
26 Jan 2006 12:48 PM
> Лось: (хотя кто сказал, что Гугль использует именно
> реляционную БД?)

Кстати, да. Это было просто предположение, которое первым пришло в голову. На самом деле, они наверняка используют какую-нибудь базу собственной разработки.
 

 

← декабрь 2005 16  17  18  19  20  23  24  25  26 февраль 2006 →
Реклама!
 

 

Место для Вашей рекламы!