Про bizwood.ru, часть 2

[ermouth]

--------------Последние новости---------------

Я нарисовал пока довольно халявные пиктограммки на заглавную и сделал для людей с отломанной кнопкой Enter кнопку “Найти” в строке поиска. Это как-то так выглядит:

Но это всё суета по сравнению с тем, что с сегодня предложения индексируются Гуглом, вау-вау. Как я это сделал для аяксового сайта, я расскажу позже в истории про зверушек под названием хэшбэнги. Особо нетерпеливым – читать Google proposal.

Ещё про меня написала местная газета для тех кому недалеко до пенсии. Меня вставили в раздел “Экономика” и сравнили с человеком со стороны, просовывающим голову в дверь. Брр. Хотя нормально так в целом, суть сохранена, но отчего-то нет сетевого адреса в статье.

----------- Конец последних новостей. --------------

Продолжение предыдущей серии

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

Калькулятор народ принял на-ура и Макс предложил мне сделать систему управления типографией, такую же клёвую и удобную. Конечно, её надо было интегрировать с калькулятором – то-есть складывать расчёты в базу данных, а потом превращать их в заказы. И не в современную такую базу типа Google Datastore, который schemaless object DB, а в самую обычную SQL-базу. С табличками.

Расчёты изначально живут в json-структурах, это деревья данных с заранее (на этапе разработки) неизвестной структурой. Мало ли какие новые типы продукции мы захотим в будущем рассчитывать. Скажем, мы начали делать горшки с росписью – а до этого визитки печатали. То-есть общего у них только цветность да тираж, а остальное всё разное совсем. И база должна такое хранить. И очень, очень быстро отдавать в виде того-же json.

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

Я такое уже делал за чужие деньги 9 лет назад, ровно в такой же задаче. Там тоже была считалка, тоже полиграфическая. И тоже надо был сохранять расчёты в MS SQL базу. Это заняло 3 месяца работы двух программистов и получилось академически безукоризненное чудовище. Выборка одного сложного расчёта могла и полминуты идти.

В этот раз меня спасло одно простое соображение – все тонкие манипуляции с данными (фильтры, сортировки, всякий мухлёж с использованием бизнес-логики) проще всего делать на клиенте, прямо в браузере пользователя.

А от базы для каждого расчёта (или строчки на Бизвуде) требуется хранить неразобранный json и несколько параметров, по которым можно сделать очень грубую выборку. Очень-очень быстро сделать. И отдать всё клиенту даже без сериализации, напрямую из базы.

То-есть база вываливает на клиента кучу мусора – интернет нынче быстрый, а json очень компактный формат. Затем браузер это всё сортирует, фильтрует и красиво рисует.

Разбор, сортировка, фильтрация и генерация html – это дорогие и медленные операции. Нефиг их делать на сервере, если у каждого даже в мобильнике практически простаивает компьютер мощностью с пентагоновскую супер-эвм розлива года этак 1975-го.

Цифры получаются такие. Одна строчка Бизвуда – это 1 килобайт от сервера до браузера. Пост жэжэшечки из одного текста без комментов – от 100 до 200 килобайт. То-есть можно спокойно отдавать за раз 200 позиций базы – и это не будет для пользователя медленно.

У Макса система, организованная по такому принципу, работает ровно полгода – без единого сбоя и без малейших тормозов. В ней больше 3000 заказов, в каждом по несколько позиций обычно. По каждой позиции сделано много операций разными людьми.

Эту систему при нагрузке Макса (20 заказов в день) запросто потянет Пентиум-300 с 64 мегами памяти. Это при том, что я ещё не экономил, да и соотношение к-ва записей и выборок примерно 1:5.

Когда я писал Бизвуд, я экономил, плюс соотношение записей к чтениям не хуже 1:100 сейчас.

Цимес такого подхода простой – легко масштабировать, ну и даже слабый хостинг выдерживает большую нагрузку.

Тут ещё есть вопрос полнотекстового поиска – но это тема для отдельной серии.

Ещё я серьёзно споткнулся о счётчик для механизма релевантности, но об этом тоже в другой раз.

Comments

[morfizm.livejournal.com]

1.
Что значит "без сериализации?".
Любая передача данных по сети есть, в своём роде, сериализация.

2.
"что с сегодня предложения индексируются Гуглом"

Два первых же примера не работают:
2.1. gahg6egj
2.2. "Цена включает сборку на готовый фундамент на территории заказчика, двускатную крышу, чёрный пол и потолок, окна, двери."

3.
У тебя всё ещё плохой usability из-за того, что сворачивание происходит по клику куда угодно, а не только по клику на "свернуть". В IE experience хуже, чем в Хроме, но в Хроме тоже плохо. Выделить и скопировать текст очень сложно. Я тебе об этом уже писал, просто FYI напоминаю :)

[ermouth.livejournal.com]

1. ну ты ведь понял, что я имел в виду. и да, любая хрень в своём роде хрень ) это я знаю.
2. это значит, впилился механизм, теперь надо подождать пока он сработает как надо, а кое-какие старые предложения подправить и заново скормить гуглу
3. это очевидно сделано намеренно -- но недодумано. сворачивать обратно будет только нажатие по верхней части раазвернутого блока, а не по всему блоку. я только вчера с этим определился и скоро это сделаю.

[morfizm.livejournal.com]

1. Вот, честно говоря, я не понял, что ты имел в виду :) Вернее, не могу сказать с уверенностью, что понял. Одно предположение - ты выплёвываешь SQL-запрос, отформатированный стандартным текстым образом, как с консоли - т.е. название колоночек, потом ============, потом строки с JSON-полями, одна за другой, в конце что-нибудь вроде "15 row(s).". А клиентом ты уже разбираешь это всё чудо. Угадал?

2. А ты проверил, что Гугл действительно цепляет то, что надо, или просто надеешься на это? (Он проиндексировал хотя бы несколько страниц, перейдя на другие по линку из контента, который сгенерён Javascript-ом? Или ты сделал site map?)

3. "это очевидно сделано намеренно -- но недодумано" - я так и подумал примерно :) Будь аккуратнее если в этой верхней части будут ссылки. Нажатие на ссылку + одновременное сворачивание - плохой эффект (я об этом тоже писал в прошлый раз, просто напоминаю).

[ermouth.livejournal.com]

1. я вкладывал абсолютно тот смысл, что написан в вики про сериализацию.
2. проверил

[morfizm.livejournal.com]

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

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

[ermouth.livejournal.com]

для json в общем случае порядок не определен, как и там откуда взялся джейсон. то есть если у тебя есть строка {z:5, y:10, x:20}, прилетевшая с сервера, и произошёл её разбор, никто не гарантирует, что итерирование по получившемуся после разбора объекту даст тот-же порядок. хотя чаще всего я ожидаю именно такое поведение -- хоть стандарт и не обязывает писателей js-движков при итерировании циклом for (key in object) {} соблюдать порядок, они его соблюдают и прямо это декларируют.

я под сериализацией понимаю то, что она обозначает. у тебя есть структура данных в памяти, а тебя её надо превратить во что-то, обычно строку, для передачи по сети или хранения.

[morfizm.livejournal.com]

OK. Строка {z:5, y:10, x:20} есть сериализация объекта, у которого z=5, etc.
Строка {y:10, z:5, x:20} другая сериализация, того же объекта. Их может быть несколько, нет проблем.

Смотрим Википедию: "Сериализация (в программировании) — процесс перевода какой-либо структуры данных в последовательность битов."

Структура данных - это абстракция. Строка - это уже последовательность битов.

Объясни мне, пожалуйста, в каком же смысле ты использовал слово "сериализация", когда написал, что передавал данные из сервера клиенту "даже без сериализации, напрямую из базы". Как можно из базы на сервере передать структуру данных в JavaScript на клиенте, минуя этап последовательности битов? (Я серьёзно. К этому моменту я уже полностью перестал понимать, что ты имел в виду).

[morfizm.livejournal.com]

"Строка - это уже последовательность битов."

(Конечно же, не просто строка, а строка в конкретной кодировке. Давай для простоты считать, что мы работаем с ASCII строками, и не смотрим на весь тот overhead, который TCP/IP добавляет, чтобы на ещё более низком уровне сериализовать строку для передачи.)

[ermouth.livejournal.com]

когда ты её хранишь уже как json.

[morfizm.livejournal.com]

Это я уже давно понял. Но сейчас до меня, кажется, дошло, что ты имел в виду под сериализацией - ты, наверное, подразумевал формирование json'а на сервере, если бы он иначе хранился. Чё-то я туплю сегодня :)

Но, вообще, если бы я AJAX-based сайт, показывающий списки с многочисленными деталями, твоя идея очень естественно легла бы. Простые рассуждения: для сериализации очень удобен JSON, т.к. в JavaScript'е его очень удобно разворачивать, с большим отрывом от любых других способов передачи структур. Вторая мысль: если разные поля retrieved всегда одновременно, их надо хранить в одном поле, чтобы было быстрее. Из этих двух мыслей уже вывод, что тебе нужен какой-то BLOB в базе, а также JSON на выходе из сервера. Совершенно естественным образом возникает минимальное по трудозатратам решение: JSON хранить прямо в базе.

[ermouth.livejournal.com]

почему то эта очевидная мысль не прослеживается ни в одной платформе, что я посмотрел (

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

[morfizm.livejournal.com]

Я не видел платформ, которые заточены под простые компактные решения. И это, кстати, наверное, открытая marketing oportunity.

Платформы обычно имеют претензию на large scale projects, с (потенциально) множественными front-end'ами, в этом случае сразу же понятно, что нельзя в базе хранить front-end-specific format (JSON). Количество abstraction layers будет больше, чем тебе нужно.

Второе - я не видел, чтобы о денормализации говорили открыто и комфортно, как о чём-то естественном и нужном. Вероятно, потому, что надо иметь голову на плечах, чтобы делать её правильно и вдумчиво. Очень легко shoot yourself in the foot и сделать супер-неэффективное & terribly unmaintainable решение с денормализацией, и сложнее shoot yourself in the foot, если соблюдать нормальные формы. Хотя если ты имплементируешь полную нормализацию для своего решения, оно усложнится в несколько раз, и ты многократно потеряешь в performance.

[ermouth.livejournal.com]

я уже писал, что в 2002 делал общее решение для хранения и выборки XML.

там было, конечно, сложнее чем с json. всё таки для описанного xsd-схемой xml-дерева важен порядок узлов (поэтому, скажем, под rss-формат xsd-схемы приемлемой нет, у него порядок узлов произвольный). также на одном уровне могут быть ветки с одинаковыми именами -- но разными типами данных. это вообще ужас.

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

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

у меня выработалась такая стратегия хранения, позволяющая несколько воспрепятствовать разрушениям целостности.

в строчке БД есть поле json, которое содержит уже собранный json, и ещё несколько полей, часть из которых приколочены по характеру содержимого (id там, тип продукта, права, владелец, компания и тд) -- а вот часть факультативны. у меня они называются p1, p2 и p3. в json-схеме конкретного продукта помимо структуры и ограничений по типам описано, мапить ли это поле/ветку на ячейку базы и на какую именно. я предположил, что в будущих продуктах вряд ли будет более трёх параметров, по которым надо будет делать быструю выборку на сервере. посмотрим.

кста, раз уж json-схема с рождения поддерживает expando на всех уровнях, прямо в схеме описаны и формы интерфейсов ввода данных.

при сохранении сервер разбирает пришедший json -- ему всё равно надо это делать для проверки соответствия схеме. одновременно при проверке конструируется запрос, который укладывает некоторые поля/ветки json-а в базу отдельными ячейками строки.

при выдаче сервер не разбирает json, а просто помимо него передаёт ещё и другие поля выбранной строки. окончательную сборку "правильного" json'а делает уже клиент. то-есть если у нас на момент сохранения компания называлась РогаКопыта, и это отлилось в металле с сохраненном json, а компания стала называться КопытаРога -- это будет исправлено.

это решение несколько избыточно -- я передаю на треть почти больше информации (некоторую два раза). успокоился я на том, что я экономлю трафик тем, что передаю кириллицу UTF-8 символами, а не escape-кодами типа \u4010, как это делают почти все на рынке из за одной и той-же недоработки почти во всех штатных json-библиотеках. это даже твиттер так делает (((

как-то так.

[ktototam-lj.livejournal.com]

А поле с отлитым json нет смысла периодически обновлять? Типа там сервер сам с собой ранним утром все пробегает и приводит компактный json к актуальному состоянию. Это, конечно, не катит для "цены", где критичен realtime, но для ИмяКомпании вполне. Или это дорого и пусть клиент делает?

[ermouth.livejournal.com]

цена как раз хранится как отдельная колонка. как и название компании (и её id).

то-есть, если клиент меняет краткое название компании (НЕ юридическое, там будет другая процедура) -- сервер сделает UPDATE по всем предложениям этой компании без разбора json.

"исторические" предложения (те, которые уже прекратили своё действие) естессно не обновляются, а активных вряд ли будет даже несколько сотен -- скорее, десятки, так что этот апдейт совершенно не затратный.

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

[ktototam-lj.livejournal.com]

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

[morfizm.livejournal.com]

"escape-кодами типа \u4010, как это делают почти все на рынке" -- ой! :(

Да, спасибо за описание. Твой дизайн вполне makes sense для твоей задачи. Но я не могу себе представить, чтобы такое писали в книгах. Оно как бы считается hacky. (Но это не тебе упрёк, а, скорее, распространённому программерскому ханжеству).

[ermouth.livejournal.com]

Ну, я бы не сказал, что это прямо уж hacky -- см NoSQL например как концепцию.

http://www.mgateway.com/docs/universalNoSQL.pdf

то-есть решения уже готовые есть, и они наголову превосходят то, что я тут на коленке насочинял.

но они за деньги и по ним довольно мало информации о надежности, скорости и других аналогичных параметрах.

плюс там могут быть неожиданные подводные камни -- Caché, скажем, на тот момент что я на неё смотрел, очень хреново дружила с UTF-8, а на дворе был год 2007-2008 примерно.

[morfizm.livejournal.com]

"для json в общем случае порядок не определен"

По поводу порядка, я имел в виду, что каждый конкретный файл/blob с json'ом -это последовательность, порядок.

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

(Тут я без привязки к твоему примеру, просто - абстрактно, про сериализацию).

[morfizm.livejournal.com]

Почитал статью, прослезился. Как будто вернулся отправился в поздние 80-е. Слушаю съезд ЦК КПСС. Читаю "Детскую Энциклопедию." Бороздим просторы вселенной, да.

[morfizm.livejournal.com]

Пиктограмки очень красивые, профессиональные. Мне нра :) Насчёт "халявных" - ты прибедняешься.

[ermouth.livejournal.com]

они кстати не размываются антиалиасом, если поставить масштаб просмотра 150% к примеру. как и логотип. но они халявные, я то знаю.

статья да, очень потешная ))

[morfizm.livejournal.com]

О, да, вижу! Ты их уменьшил вдвое, хихи :)

[net-cat.livejournal.com]

"А я сразу смотрю и думаю, что не каждый предприниматель захочет выставить свою цену напоказ, у каждого свой подход к делу... Мы размещали свою рекламу в Интернете. Посыпалось столько звонков, что нам столько и не надо. Есть какие-то сформировавшиеся отношения с покупателями..."

Убило просто.

[morfizm.livejournal.com]

+1.
Не каждый предприниматель хочет заниматься производством и продажей. Некоторым куда интереснее социальный аспект (формировать отношения...) :)

[ermouth.livejournal.com]

журналистка исковеркала смысл. мужик разместил рекламу у нас в журнале Терем -- и стал отбиваться от звонков.

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

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

[morfizm.livejournal.com]

"потому что у него просто нет леса, чтобы делать больше продукции"

А почему ему в голову не пришла идея повышать немножко цену, пока количество звонков не станет в точности заполнять объёмы его предложения?

[ermouth.livejournal.com]

если коротко, потому что он не уверен в своём завтра. это длинная история за рамками нашего разговора -- но это, к огромному несчастью, так и есть.

[niklisin.livejournal.com]

Идея классная, удачи тебе.

[ermouth.livejournal.com]

спасибо, бро!

[rogarik.livejournal.com]

Навело на мысли о гильтине? :))))

Из статьи показалось, что вместо того, чтобы предлагать стадартизированную цену на товар, предприниматели предпочитают встречать клиента по одежке. Они не поняли, что продажи по интернету - это сила и сайт поможет донести информацию например о постройке дачи до туевой куевой хучи everyman, до тех которые давно хотят или в принципе хотели бы, но не знают с чего начать и куда податься. Чем собсстно заказ дома отличается от заказа пиццы по интернету? Вдруг окажется, что это также просто и доступно. Разве не вау?

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

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