суббота, Август 05, 2006
Google BigTable адаптивно распределяет массивы данных по Google File System
Как заметил бывший президент легендарной AT&T Labs: "нормальное индексирование перестанет работать," когда базы данных дорастут до петабайтовых размеров. Пока для большинства из нас петабайтовые массивы остаются делом будущего, сетевые провайдеры вычислений с ними сталкиваются уже сегодня. В этом контексте их пионерский опыт представляет практический интерес.
Jeff Dean довольно подробно рассказывает в University of Washington о BigTable, одной из инфраструктурных технологий Google. На ней построена в том числе реализация subversion, входящая в состав недавно увидевшего свет Google Project Hosting.
API BigTable, а может и академическая среда лекции, сильно напомнила мне известную с 1980-х распределенную модель программирования Linda. (Отличия, конечно, есть: например, BigTable использует схему данных, хотя и нежесткую, в то время как в базовой модели Linda схемы нет.)
Но еще больше API BigTable напомнил мне собственноручно разработанный API нашего продукта UnitSpace BCR. Здесь и именование "рядов", и "семейственность" атрибутов, и естественная навигация вперед-назад по хранимым сущностям. Только для их идентификации мы применяем URI (а не строку), что позволяет сегментировать пространство хранилища на отдельно управляемые иерархические разделы. И имена атрибутов также являют собой URI, привязанный к записи в общем реестре метаданных. В качестве последнего годится любой UDDI-совместимый каталог, в который же публикуются и сервисы, создаваемые путем point-and-click в административной консоли BCR и описываемые с использованием всех этих метаданных для возможного последующего динамического обнаружения и связывания. Вот вам, кстати, и слабое связывание, которым изначально была так привлекательна Linda, причем как runtime, так и design-time.
Большая же часть лекции посвящена не столько API, сколько описанию основных деталей реализации. В них тоже много интересного, но мое особое внимание привлекла архитектура "целого решения", включающая, помимо BigTable, GFS, Scheduler и Lock Service, систему параллельных вычислений MapReduce. Очевидно, что MapReduce и BigTable хорошо дополняют друг друга при реализации распределенной обработки больших массивов данных. В нашем случае таким дополнением служит BPEL (Web-сервисы, порождаемые UnitSpace BCR, идеально подходят для оркестрации).
Как я уже упоминал, именно в малозаметной сфере инфраструктуры коммунальных IT-служб (в том числе т. н. Web 2.0) следует искать наиболее интересные технологические инновации будущего.
Jeff Dean довольно подробно рассказывает в University of Washington о BigTable, одной из инфраструктурных технологий Google. На ней построена в том числе реализация subversion, входящая в состав недавно увидевшего свет Google Project Hosting.
API BigTable, а может и академическая среда лекции, сильно напомнила мне известную с 1980-х распределенную модель программирования Linda. (Отличия, конечно, есть: например, BigTable использует схему данных, хотя и нежесткую, в то время как в базовой модели Linda схемы нет.)
Но еще больше API BigTable напомнил мне собственноручно разработанный API нашего продукта UnitSpace BCR. Здесь и именование "рядов", и "семейственность" атрибутов, и естественная навигация вперед-назад по хранимым сущностям. Только для их идентификации мы применяем URI (а не строку), что позволяет сегментировать пространство хранилища на отдельно управляемые иерархические разделы. И имена атрибутов также являют собой URI, привязанный к записи в общем реестре метаданных. В качестве последнего годится любой UDDI-совместимый каталог, в который же публикуются и сервисы, создаваемые путем point-and-click в административной консоли BCR и описываемые с использованием всех этих метаданных для возможного последующего динамического обнаружения и связывания. Вот вам, кстати, и слабое связывание, которым изначально была так привлекательна Linda, причем как runtime, так и design-time.
Большая же часть лекции посвящена не столько API, сколько описанию основных деталей реализации. В них тоже много интересного, но мое особое внимание привлекла архитектура "целого решения", включающая, помимо BigTable, GFS, Scheduler и Lock Service, систему параллельных вычислений MapReduce. Очевидно, что MapReduce и BigTable хорошо дополняют друг друга при реализации распределенной обработки больших массивов данных. В нашем случае таким дополнением служит BPEL (Web-сервисы, порождаемые UnitSpace BCR, идеально подходят для оркестрации).
Как я уже упоминал, именно в малозаметной сфере инфраструктуры коммунальных IT-служб (в том числе т. н. Web 2.0) следует искать наиболее интересные технологические инновации будущего.
technorati tags: google, bigtable, utility computing, innovation
LinkedIn
vCard
Лента
