s0rr0w

У меня есть стойкое ощущение, что вы спорите сами с собой, вернее со своими фантазиями. Он дорогой по причине написания собственных аналогов индексирования, парсера запросов, служебных утилит. Кэш в памяти еще быстрее, да впридачу гораздо дешевле при хранении в удобном виде в базе. Так что связка кэш+СУБД для меня предпочтительнее собственноручно написанных поделок. А кто сказал, что код обязательно должен быть сложным? Например, мой вариант легко реализуется материальной вьюхой, все накладные расходы по поддержанию консистентности, о которой вы так печетесь, берет на себя база. Приведу алгоритм серверного скрипта для моей реализации1. Коннектимся к базе 2. Запрашиваем строку с нужным словом из матвьюхи или кэш-таблицы 3. Делаем эхо json-а. Сравниваем с "классическим" вариантом 1. Коннектимся к базе 2. Запрашиваем перечень синонимов 3. Из этого перечня в цикле склеиваем json 4. Выплевываем json Что делаем, если поменялся формат json-a? 1й способ. Ничего 2й способ. Переписываем запрос и конкатенатор json-а (90% кода!!!) Да, в первом способе все равно приходится делать изменения, но уже в другом месте. Какие плюсы первого подхода? + не требуется повторное тестирование данного участка кода при изменениях форматов данных + не требует обновления кода на продакшин-системе, меняются только данные + тупейший код, который имеет предсказуемую скорость выполнения при любых условиях Посчитайте, что дешевле, купить новый сервер за 10килобаксов, или на 1к винтов докупить? Миллион записей не будет занимать террабайты, это будет гигабайт 100 максимум. Не размеры для текущих накопителей. Кстати, советую почитать про методику XP, тогда мои высказывания не будут вызывать приступы беспричинного смеха Кстати, тестирование скорости различных запросов http://www.andrewrollins.com/2009/06/21/mysql-join-performance/

У меня все как раз хорошо считается простой математикой. Даже если денормализация будет занимать в 100 раз больше времени, чем разница между джойн и неджойн реализацией, то я это время легко отобью со временем. Затем, что они участвуют в поиске наиболее релевантных текстов. Без них можно, но падает качество обработки. Со временем придет понимание, что решения "в лоб" или "как привык" обходятся очень дорого. Особенно в тех случаях, когда исходные данные занимают сотни гигабайт. Экспорт в файловую систему - еще дороже обойдется. Я давно уже практикую правило, что лучше день потерять, но потом за 5 минут долететь. Стоимость программного продукта не равна стоимости первичной разработки, а включает в себя еще и стоимость модификаций в дальнейшем. Так вот, чем дешевле производить модификации - тем выгоднее получается. Выполнение этого требования вынуждает применять более дорогостоящие решения в начале, но они с лихвой окупаются в конце. Зачем? В разных DB эти принципы идентичны, но очень сильно отличаются в реализации. И это накладывает свои ограничения. Это не интересно. На таком объеме все легко умещается в памяти. Нет ни дискового IO, ни накладных расходов самой базы. На таком объеме денормализация будет действительно дорогостоящим решением. Его вопрос был вполне четким Структура таблиц для быстрого поиска слов Так как объемы данных не были определены, то логично предположить, что их будет ровно столько, сколько и слов в нескольких языках. И узнать больше о проблемах - это гораздо интереснее, чем получить только один SQL-запрос.

Эффективнее по каким параметрам? Как вы вообще эффективность посчитали? Т.е. бесконечно переделывай архитектуру? Бугагашеньки. Хайлоад архитектура - это фикция. Она просто имеет возможность масштабироваться либо горизонтально, либо вертикально. Легко. Контент-анализ Если вы не понимаете прелесть решения, то это не значит, что его там нет. Если брать решение задачи только на уровне БД, то да, мой вариант похож на 5-е колесо. Но если провести полный цикл действий над данными, и доставить их потребителю, то тут суммарный код станет гораздо проще, потому что серверная сторона будет работать в качестве "прокси" по прямой передаче данных из базы клиенту. Кто готовит эти данные - пофиг, взял из базы, выплюнул в stdout, и забыл. А подготовка данных к выдаче будет абсолютно автономна и не зависеть от местоположения данных, таблиц, количества обрабатывающего кода. Обновляй в оффлайне себе и радуйся.

Экономия вполне определенная. Вместо докупки новых серверов достаточно будет просто докупить HDD, которые стоят копейки. Предлагаю провести эксперимент и доказать, что JOIN будет всего на 20% менее эффективным при решении данной задачи. Количество данных - миллион строк.

JOIN кушает ресурсы. И чем больше записей в таблице, тем больше с ним придется возиться. Избыточность не страшна, так как на одну процедуру записи данных будут миллионы чтения. И что лучше, миллион раз применять JOIN и процедуру пост-обработки данных, или сделать это один раз и потом пользоваться результатами? Я за последний вариант.

Я понял, что вас смущает. Из контекста не нужно вырывать. Без предыдущего поста rus'а мои слова действительно можно истолковать как хранение. Нет, хранить так без нормального представления противопоказано.

Этого в описании архитектуры нет. И при чем тут превышение трафика обновления кеша над скоростью запроса данных? Итак, имеем две таблицы | id | word | syn | и | id | syn_id | Существует два процесса - обновление данных и денормализация. При обновлении мы должны найти слово в базе, изменить его значение word и обнулить syn. Вытаскиваем данные по синонимам слова. При добавлении мы должны вставить новое слово. Найти все записи со словами-синонимами, и добавить их идентификаторы в таблицу связей. При удалении процедура аналогичная добавлению, за исключением того, что связи и слово удаляются. Далее запускаем процедуру денормализации для списка синонимов и для искомого объекта, если это не удаление. Меня спрашивали как данные выводить, а не хранить. В этом решении есть проблема. Две группы слов могут иметь пересечение синонимов, но не полностью совпадать. Тогда его решение рассыпается как карточный домик. Слову "делать" синонимами могут быть слова "изготавливать" и "реализовывать", но вот слову "реализовывать" может быть синонимом слово "продавать". А "продавать" не является синонимом слово "делать". Конечно не о чем.

Почитайте про новую архитектуру Гугла. С их объемами это вполне реально. А кто вам сказал, что нужно искать именно в json'e? Вариант с двумя полями вас не устраивает? Одно поле - слово, второе - json. Ищется по первому полю, результат берется из второго. А я и не мешал. Это вы себе придумали что-то, потом спорите со своими фантазиями. Вы задачу человека внимательно прочитали? Ему нужно быстро искать данные и легко получать связку синонимов. Мой вариант идеально подходит для решения задачи, мало того, хорошо масштабируется и позволит выгружать данные в тот же редис, монго или мемкешед. А как именно будет происходить работа с нормализованными данными, это уже не столь важно. Тут применять классическое решение и не заморачиваться: таблица-словарь со словами и таблица связей.

Проводя денормализацию. В кеше и хранятся денормализованные данные. А кэш иногда проще вообще не использовать, так как затраты на обновление кеша могут привысить затраты на обработку запроса базой. В чем проблема? Вам нужно всего лишь обновить n строк, где n - количество синонимов в группе. Это предсказуемое количество. Только весь прикол в том, что один запрос оффлайновый, а второй - онлайновый. И да, я получу адский профит на всех этапах. Потому что мне не нужно будет собирать каждый раз таблицу в удобоваримый для передачи дальнейшим обработчикам вид, например, в тот же json.

Да конечно! Во всем мире это используется в высоконагруженных системах, а у него это говнокод. Эта структура может быть использована для хранения нормализованных данных, но не для вывода. Потому что там JOIN надо применять. В моем варианте нужно найти всего одну строку и как есть отправить на обработку.

Только так и надо решать. Можно сразу хранить json-объект (вернее его текстовое представление) Тогда запрос будет простым и быстрым.

Вам матчасть нужно, или готовый код? Если готовый код, то вы ошиблись немного форумом.

По-русски, это все способы узнать, что же там закодировано

Три секунды гугления http://unix.stackexchange.com/questions/12273/in-bash-how-can-i-convert-a-unicode-codepoint-0-9a-f-into-the-printabale-char

Попробуйте использовать iconv

Или лошок, чтобы за него работу делать

Так можно после загрузки фрейму src="about:blank" присваивать Теоретически, да. Про кешировани не забываем. Не понял проблему. Как загрузить данные в div?

Самая главная проблема - определить, кто именно отвечает за "нужную часть" и могут ли загружаться разные части одной страницы. Как это устроено в упрощенной схеме 1. iframe располагается за пределами экрана, например с position: absolute; top: -1000px;. Ему присваивается имя, например "proxyFrame" 2. Ссылкам присваивается target="proxyFrame" и при нажатии будет загружен контент в наш проксифрейм 3. По окончанию загрузки дочерней страницы нам нужно проверить, мы загружены во фрейме или нет. Если во фрейме, то идем дальше, иначе прекращаем работу скрипта 4. Находим нужный нам контент в дочерней странице и присваиваем его innerHTML какому-то контейнеру в родительском документе. Как узнать, куда именно загружать контент? Можно по клику на ссылку фрейму записывать какой-то параметр со ссылкой или на id, или на конкретную ноду, в которую нужно вставить контент. Тут уже по вкусу. Какие есть проблемы? С одним проксифреймом все запросы должны быть строго последовательными. Избавиться от этого можно путем генерации для каждой ссылки своего собственного проксифрема.

Все ajax-плагины к jQuery используют iframe для аплоада файлов. gmail использует iframe'ы. Потому что 1. Native history 2. Есть стандартная индикация загрузки данных у браузера 3. Можно работать с множеством типов данных, не только с текстом Посмотрите на http://cs.iptcom.net

Для подгрузки HTML-контента нужно использовать не XMLHttpRequest, а iframe

На определенном этапе развития ты поймешь, что изучения языка сводится к изучению нюансов. Указатели нечего учить, это не сложнее прототипов в JS. С времен DOS'а, 16-ти битного адресного пространства и отсутствия виртуализации, работа с памятью упростилась в разы.

А кто тебе сказал, что он все это знает досконально? Как архитектор, он большинство языков и технологий знает на уровне "понимаю сильные и слабые стороны". Но если начать спрашивать про какие-то уникальные особенности, мы услышим вполне резонную фразу - мне это не нужно, я на другом уровне работаю. Например, я могу профессионально работать в векторных и растровых программах, могу на Flash'е разработку вести, могу макросы под Ворды и Эксели на VB строчить, могу на bash'е нафигачить парсер контента. Но в большинстве случаев я про это молчу.

А что тебя так расстраивает? Обычное резюме. Не нашел ничего сверхъестественного или уникального.

Так в теме их валом. Другой вопрос, что вы не совсем понимаете, как это работает

empty() is the opposite of (boolean) var, except that no warning is generated when the variable is not set.