Column-oriented архитектура

6yrop

Сейчас никто не думает колонками, сейчас все думают сущностями. Это и в ООП. Это же в любом фрейворке. Думать колонками – такое я встретил только в известной работе Кодда. А ведь часто именно колонки чётко видны в системе, а сущности надо высасывать из пальца. Почему так?

6yrop

А ведь часто именно колонки чётко видны в системе, а сущности надо высасывать из пальца.
Для убедительности приведу цитату из книжки Фаулера:

Layering is an important technique, but there are downsides.
Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes.
The classic example of this in a layered enterprise application is adding a field that needs to display
on the UI, must be in the database, and thus must be added to every layer in between.
...
But the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be.
ftp://ftp.heanet.ie/mirrors/sourceforge/w/we/webtune/Pattern...

Dasar

Что такое колонка? и чем она отличается от поля?

6yrop

это синонимы в данном случае
колонка более отличимое слово

luna89

Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes.
The classic example of this in a layered enterprise application is adding a field that needs to display
on the UI, must be in the database, and thus must be added to every layer in between.

Я встречался с намного более серьезной проблемой, когда разрабатывал сильно кастомизируемый софт. У нас были слои A, B, C. Сущность инициализировалась в слое A, потом проходила через все другие слои. Мне надо было прицепить какие-то параметры к сущности в слое B, чтобы воспользоваться ими в слое С, но при этом я не мог менять класс сущности и добавлять в него какие-то поля! В результате у нас в таких сущностях было поле типа хэш, в которое можно было напихать каких-угодно атрибутов.
При динамической типизации сущность была бы простым хэшем, и в него можно было бы пихать какие угодно данные.

Hastya

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

Dasar

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

6yrop

поля отображаются на поля :)
а вот языковые средства для удобной работы с ними, да, надо развивать
те же C# анонимные классы — первые шаги в этом направлении, в блоге Demon видел какой-то язык с хорошей поддержкой кортежей с именованными полями
ну и JS хорош отчасти именно потому, что базируется на полях

Papazyan

Да вообще-то много языков, где класс определяется полями, а не наоборот. Это тухлые динозавры типа С++. джавы в числе отстающих.

6yrop

это какие из применяемых в промышленности?

karkar

Полагаю, речь об этом:
http://en.wikipedia.org/wiki/Structural_type_system
В примерах там OCaml, Go, Haxe, частично С++ (и D туда же). На уровне туплов есть еще в куче мест.

6yrop

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

Kira

кортежей с именованными полями
а в чем концептуальное отличие этого от тех же структур/объектов с readonly свойствами?

karkar

Такое?
Tuple!(int, "a", string, "b") t = tuple(99, "bottles");

writeln(t.a, " ", t.b);

Это D.

6yrop

не, у тебя (или по ссылке из твоего блога) было более красивое, с выводом типов. Например, тапл, элементы которого тоже таплы, без вывода типов будут ужасны.

6yrop

а в чем концептуальное отличие этого от тех же структур/объектов с readonly свойствами?
концептуальное в том, что нет структуры/класса.

6yrop

вот нашел http://thedeemon.livejournal.com/61046.html

6yrop

а этот Haxe не сказать, что какой-то серьезный промышленный язык

karkar

А, ну там это скорее анонимные классы, чем туплы.
Что до серьезности, то это мера не самая серьезная. :) Для флеша ничего лучше Haxe нет, например.
Пару коммерческих проектов на нем я успешно делал.

6yrop

А, ну там это скорее анонимные классы, чем туплы.
почему? вроде слово tuple это из реляционной модели, а там как раз у атрибутов имена, а не индексы.

6yrop

кстати еще вопрос, в каком языке для дженериков можно имена использовать вместо индексов?

karkar

Для дженериков? Вместо индексов? Щито? Я ничего не понял.

6yrop

Для дженериков? Вместо индексов? Щито? Я ничего не понял.
ну чтобы писать не так:
 

Foo<MyType1, MyType2>

 

 

Foo<genericParamNameX: MyType1, genericParamNameY: MyType2>

частичный вывод типов с этим хорошо сочитается

Dasar

еще интересно, есть ли где генерики с возможностью замены имен полей.
что-то типа такого:


class Tuple<T1, T2, name N1=N1, name N2=N2>

{

   public T1 N1;

   public T2 N2;

}



bool AreEquals<T1, T2>(Tuple<T1, T2> t1, Tuple<T1, T2> t2)

{

   return t1.N1 == t2.N1 && t1.N2 == t2.N2;

}



var point1 = new Tuple<int, int, X, Y>

point1.X = 5;



var point2 = new Tuple<int, int, X, Y>{X = 5, Y = 0};



Console.WriteLine(AreEquals(poin1, point2;

karkar

А, теперь понял. Речь о порядке передачи параметров. В си-подобных языках не припомню такого.
В Окамле есть похожее: если есть интерфейс модуля с абстрактными типами, при описании инстанса модуля конкретные типы указываются по именам, поэтому порядок неважен. Нормальный пример сейчас лень придумывать, а идиотский но компилирующийся пример выглядит так:
module type Pair = sig

    type a

    type b

    val pair : a * b

end



module M = (struct type b = string type a = int let pair = (99, "bottles") end 

           : Pair with type b = string and type a = int);;



print_int (fst M.pair);;

Тут Pair - грубо говоря генерик, а М - инстанс оного с конкретными типами и значениями.

karkar

Выше был пример на D где имена полей как раз в параметрах передавались.
Их же можно в произвольную функцию передать, в духе: вот тебе два заранее не известных типа и пара имен полей, на которые там надо смотреть.

Dasar

Выше был пример на D где имена полей как раз в параметрах передавались.
оно при этом строго типизированное? т.е. проверяются ли все соответствия имен и типов при компиляции при этом?

karkar

Да, разумеется. Никакой динамики там.

6yrop

Я встречался с намного более серьезной проблемой, когда разрабатывал сильно кастомизируемый софт. У нас были слои A, B, C. Сущность инициализировалась в слое A, потом проходила через все другие слои. Мне надо было прицепить какие-то параметры к сущности в слое B, чтобы воспользоваться ими в слое С, но при этом я не мог менять класс сущности и добавлять в него какие-то поля! В результате у нас в таких сущностях было поле типа хэш, в которое можно было напихать каких-угодно атрибутов.
да, такое встречается часто — неумехи статический язык превращают в динамический недоязык

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

Динамический язык ситуацию не спасает. В field-oriented архитектуре принцип divide and conquer относится к полям — фрагменты кода, относящиеся к заданному полю, легко отделимы от остальных частей кода.
Свалив field-ы в нетипизированный хэш, как ты сможешь разделить код на тот, который относится в заданному полю MyField и тот который не имеет отношение к полю MyField?

6yrop

Если ты о том, что в реляционной модели называют DOMAIN
более точно это домены с добавлением роли:

Для достижения этого домены должны быть однозначно идентифицируемы, по крайней мере, в пределах любого данного отношения, без использования их позиции. Таким образом, там, где существует два или более одинаковых домена, мы требуем, чтобы в каждом случае имена доменов были уточнены отдельным именем роли, служащим для указания роли, которую этот домен играет в данном отношении. http://citforum.ru/database/classics/codd/
 

Забавная ситуация получается. Кодд называл словом "домен" колонки, а Фаулер и прихлебатели загадили этот термин какими-то сущностям.
 
ими почти никто не пользуется - видимо, толку никакого.

чем не пользуются полями/колонками/атрибутами? :confused: 90% работы по созданию enterprise приложений вокруг них крутится.

psm-home

field-oriented архитектуре
А есть пример такой архитектуры? В идеале конечно исходный код приложения бы посмотреть (2014 год, я избалован гитхабом но хорошая статья тоже подойдет.

6yrop

2014 год, я избалован гитхабом
запость, плиз, несколько ссылок чем ты избалован

psm-home

нет ты!
---
Впрочем, я попробую немного раскрыть тему. Вот, скажем есть такая штука, Dropwizard, очередной фреймворк для приложений на Java, такой же как 100500 до него, но другой. Я читаю доку на него (отличную, кстати) и думаю, теперь бы пример real world app увидеть. Роюсь в поиске на гитхабе и нахожу MultiBitMerchant, вполне себе пример.

luna89

Вот, скажем есть такая штука, Dropwizard, очередной фреймворк для приложений на Java, такой же как 100500 до него, но другой.
Что меня всегда восхищало в джава-программистах - так это умение гордо целыми пакетами писать код, который вообще ничего не делает полезного. Вот пример:
http://github.com/dropwizard/dropwizard/tree/master/dropwiz...

6yrop

В github-е код UI-я лежит или нет? Я пока не смог найти, вроде всё папочки прокликал, но мог пропустить из-за вот такой вложенности
mbm-hal/src/main/java/org/multibit/mbm/client/interfaces/rest/api/hal

psm-home

Там нет кода клиента, потому что это сервер. Вообще dropwizard заточен под относительно удобное (насколько это может быть удобно на яве) создание REST сервисов. И MultiBitMerchant как раз про это. Демо клиент к MultiBitMerchant вроде бы MultiBitStore.

6yrop

http://multibit-store.herokuapp.com
Какой-то примитивный сайтец. Причем сильно не доделан, изменение Qty с 1 на 2 падает с ошибкой. Имхо, не катит за сколько-нибудь авторитетную реализацию.

6yrop

Для начала обсуждения column-oriented архитектуры на текущий момент есть вот такой код:
http://dl.dropboxusercontent.com/u/82980501/Temp/LC.7z
Запускать проект LibraryCatalog

kokoc88

Для начала обсуждения column-oriented архитектуры на текущий момент есть вот такой код:
Бля, зачем я открыл этот архив?...

6yrop

Открывать надо солюшен LibraryCatalog.sln. Запускать проект LibraryCatalog.

Dasar

пример какой-нибудь можно?

6yrop

Надо открыть солюшен под IDE и увидеть, что посредством навигации можно полностью проследить код, относящийся к заданному полю (например, "Название книги") от UI-я до БД или в обратном направлении.
Еще надо дописать:
1. Переход на TypeScript.
2. Сделать формирование html на клиенте.
Пример сайта надо получше подобрать. Этот случайно появился, я не думал его выкладывать, просто раз уж речь зашла об имеющихся примерах.

Dasar

кстати, что Column-oriented подход говорит про одну и ту же характеристику, но для разных сущностей?
т.е., например, Name автора и Name книги - это одно и тоже, или нет?

6yrop

Сильно зависит от ситуации. Можно представить ситуацию, когда нужен запрос аналогичный вот такому:
SELECT Name FROM Book UNION ALL SELECT Name FROM Author

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

apl13

кстати, что Column-oriented подход говорит про одну и ту же характеристику, но для разных сущностей?
т.е., например, Name автора и Name книги - это одно и тоже, или нет?
"Sex?"
"Three times a week."
"Male or female!"
"Male, female, sometimes camel..."
Оставить комментарий
Имя или ник:
Комментарий: