Собрал и поставил HyperTable. Пока не пробовал -- завален говноработой. В гугле работают реально крутые перцы. А почему? Потому что максимально используют готовое (Boost, BerkeleyDB) и пишут простой код. То есть плоский как стол. Тем не менее он судя по всему умеет делать все, ему приписываемое, то есть заполнять распределенную файловую систему равномерно заполяняя дисковое простанство хостов заданными шагами( по умолчанию -- 200 мегабайт), по мере заполнения шагов, переключаясь на заполнение соседних по IP хостов. Ну а потом -- сначала и с учетом подключения новых узлов. Сказка. GridSQL меня сильно разочаровал тем, что кластеризующий софт, объединяющий теоретически неограниченное (пространством IP-диапазона пожалуй) кол-во серверов Postgres в один виртуальный мега-сервер. Сие ПО написано на Java, что лично для меня в критических приложениях ( к коим отношу и БД) является неприемлемым. Да, я в курсе про J2EE, однако ж замечу, что это все для решений если и не клиентского, то промежуточного уровня. БД же должна стоять как скала и работать быстро -- допускаю, что Java может гарантировать каждое из условий по отдельности. Так что помимо С++ все идет лесом. На первый взгляд, в GridSQL Java занимает именно промежуточный слой -- она обслуживает таблицы метаданных для адресации "сырых" хостов. Все равно не нравится, т.к. как раз запрос к метаданным должен быть сверхбыстрым -- остальное время займет сбор и пересылка по grid-сети запрошенного сырья. Понятно, что пересылка в случае какой-нить 100 Гбит-оптики пренебрежимо мала, но сбор-то займет время и я совсем не уверен, что система умеет хорошо оптимизировать выдачу конвейеризацией: построение метавыборки ==> сбор сырья, не дожидаясь полного построения. То есть понятно, что конвейеризует ибо метавыборка может быть на десятки миллионов строк, но насколько хорошо Java с этим справится -- вот в чем вопрос. Пусть даже SQL-трансляция там прозрачна и препроцессинг даже делает сама Java дабы быстрее исполнялась на сырых хостах, все равно -- среды выполнения разнородны и никуда от этого не убежишь. А работают на одном уровне представления данных -- серверном.
HyperTablе лучше тем, что она вся на С++ и метаданные сами можно расположить на большом кластере, сильносвязанном, конечно ибо подсистемы Master и Hyperspace (связь с клиентами и метавыборка соответственно) являются синглтонами -- запускаются в единственном экземпляре каждая (подистемы, а не процессы). Но здесь разнородность на уровне ниже -- между серверным представлением и файловой системой, т.е. с семантической точки зрения именно распределенный, потенциально необозримый сервер БД.
Я прошу прощения у френдов за то, что ударился в это занудство -- не о чем писать. В real-life -- одно сплошное разочарование, так что о ней писать -- выйдет еще хуже. Спасибо за понимание.
HyperTablе лучше тем, что она вся на С++ и метаданные сами можно расположить на большом кластере, сильносвязанном, конечно ибо подсистемы Master и Hyperspace (связь с клиентами и метавыборка соответственно) являются синглтонами -- запускаются в единственном экземпляре каждая (подистемы, а не процессы). Но здесь разнородность на уровне ниже -- между серверным представлением и файловой системой, т.е. с семантической точки зрения именно распределенный, потенциально необозримый сервер БД.
Я прошу прощения у френдов за то, что ударился в это занудство -- не о чем писать. В real-life -- одно сплошное разочарование, так что о ней писать -- выйдет еще хуже. Спасибо за понимание.