Првите впечатоци од Амазон Нептун

Поздрав, жители на Хабровск. Во пресрет на почетокот на курсот „AWS за програмери“ Подготвивме превод на интересен материјал.

Во многу случаи на употреба што ни се допаѓаат бакдатКако што гледаме на веб-локациите на нашите клиенти, релевантните информации се скриени во врските помеѓу ентитетите, на пример кога се анализираат односите меѓу корисниците, зависностите помеѓу елементите или врските помеѓу сензорите. Ваквите случаи на употреба обично се моделирани на графикон. Претходно оваа година, Амазон ја објави својата нова база на податоци за графикони, Нептун. Во овој пост сакаме да ги споделиме нашите први идеи, добри практики и што може да се подобри со текот на времето.

Зошто ни требаше Амазон Нептун

Базите на податоци со графикони ветуваат дека ќе се справуваат со високо поврзани множества на податоци подобро од нивните релациски еквиваленти. Во таквите збирки на податоци, релевантните информации обично се складираат во односите помеѓу објектите. Користивме неверојатен проект за отворени податоци за да го тестираме Нептун MusicBrainz. MusicBrainz собира секаков вид музички метаподатоци што може да се замисли, како што се информации за изведувачи, песни, изданија на албуми или концерти, како и со кого соработувал изведувачот зад песната или кога албумот бил издаден во која земја. MusicBrainz може да се гледа како огромна мрежа на ентитети кои се некако поврзани со музичката индустрија.

Базата на податоци MusicBrainz е обезбедена како CSV депонија на релациона база на податоци. Вкупно, депонијата содржи околу 93 милиони редови во 157 табели. Додека некои од овие табели содржат основни податоци како што се изведувачи, настани, снимки, изданија или песни, други табели за врски — зачувување на односите помеѓу уметници и снимки, други изведувачи или изданија, итн... Тие ја демонстрираат структурата на графиконот на множеството податоци. При конвертирање на базата на податоци во RDF тројки, добивме приближно 500 милиони примероци.

Врз основа на искуството и впечатоците на проектните партнери со кои работиме, претставуваме амбиент во кој оваа база на знаење се користи за добивање нови информации. Дополнително, очекуваме редовно да се ажурира, на пример со додавање нови изданија или ажурирање на членовите на групата.

прилагодување

Како што се очекуваше, инсталирањето на Амазон Нептун е едноставно. Таа е доста детална документирани. Можете да стартувате база на податоци за графикони со само неколку кликања. Меѓутоа, кога станува збор за подетална конфигурација, потребни информации тешко да се најде. Затоа, сакаме да укажеме на еден параметар за конфигурација.

Слика од екранот за конфигурација за групи на параметри

Амазон вели дека Нептун се фокусира на трансакциските оптоварувања со ниска латентност, поради што стандардниот истек на барањето е 120 секунди. Сепак, тестиравме многу случаи на аналитичка употреба во кои редовно ја достигнувавме оваа граница. Овој истек на време може да се смени со создавање нова параметарска група за Нептун и поставување neptune_query_timeout соодветно ограничување.

Се вчитуваат податоци

Подолу ќе разговараме во детали како ги вчитавме податоците од MusicBrainz во Нептун.

Врски во тројца

Прво, ги конвертиравме податоците од MusicBrainz во RDF тројки. Затоа, за секоја табела, дефиниравме шаблон кој дефинира како секоја колона е претставена во тројката. Во овој пример, секој ред од табелата со изведувачи е мапиран на дванаесет RDF тројки.

<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/gid> "${gid}"^^<http://www.w3.org/2001/XMLSchema#string> .
 
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/name> "${name}"^^<http://www.w3.org/2001/XMLSchema#string> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/sort-name> "${sort_name}"^^<http://www.w3.org/2001/XMLSchema#string> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/begin-date> "${begin_date_year}-${begin_date_month}-${begin_date_day}"^^xsd:<http://www.w3.org/2001/XMLSchema#date> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/end-date> "${end_date_year}-${end_date_month}-${end_date_day}"^^xsd:<http://www.w3.org/2001/XMLSchema#date> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/type> <http://musicbrainz.foo/artist-type/${type}> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/area> <http://musicbrainz.foo/area/${area}> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/gender> <http://musicbrainz.foo/gender/${gender}> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/comment> "${comment}"^^<http://www.w3.org/2001/XMLSchema#string> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/edits-pending> "${edits_pending}"^^<http://www.w3.org/2001/XMLSchema#int> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/last-updated> "${last_updated}"^^<http://www.w3.org/2001/XMLSchema#dateTime> .
 
<http://musicbrainz.foo/artist/${id}> <http://musicbrainz.foo/ended> "${ended}"^^<http://www.w3.org/2001/XMLSchema#boolean> .

масовно поставување

Предложениот начин да се вчитаат големи количини на податоци во Нептун е преку процесот на масовно испраќање преку S3. Откако ќе ги поставите вашите тројни датотеки на S3, го започнувате поставувањето користејќи барање POST. Во нашиот случај, потребни се околу 24 часа за 500 милиони тројки. Очекувавме дека ќе биде побрзо.

curl -X POST -H 'Content-Type: application/json' http://your-neptune-cluster:8182/loader -d '{
 
 
 "source" : "s3://your-s3-bucket",
 
 "format" : "ntriples",
 
 "iamRoleArn" : "arn:aws:iam::your-iam-user:role/NeptuneLoadFromS3",
 
 "region" : "eu-west-1",
 
 "failOnError" : "FALSE"
 
}'

За да го избегнеме овој долг процес секогаш кога ќе го лансираме Нептун, решивме да го вратиме примерот од снимката во која овие тројки веќе беа вчитани. Извршувањето од снимка е значително побрзо, но сепак трае околу еден час додека Нептун не биде достапен за барања.

Кога првично вчитувавме тројки во Нептун, наидовме на различни грешки.

{
 
 
 "errorCode" : "PARSING_ERROR",
 
 "errorMessage" : "Content after '.' is not allowed",
 
 "fileName" : [...],
 
 "recordNum" : 25
 
}

Некои од нив беа грешки при парсирање, како што е прикажано погоре. До денес, сè уште не сме сфатиле што точно тргнало наопаку во овој момент. Овде дефинитивно би помогнале малку повеќе детали. Оваа грешка се појави за приближно 1% од вметнати тројки. Но, што се однесува до тестирањето на Нептун, го прифативме фактот дека работиме само со 99% од информациите од MusicBrainz.

Иако ова е лесно за луѓето запознаени со SPARQL, имајте предвид дека RDF тројките мора да бидат означени со експлицитни типови на податоци, што повторно може да предизвика грешки.

Преземање на стриминг

Како што споменавме погоре, не сакаме да го користиме Нептун како статична продавница за податоци, туку како флексибилна и еволутивна база на знаење. Затоа, требаше да најдеме начини да воведеме нови тројки кога се менува базата на знаење, на пример кога се објавува нов албум или кога сакаме да го материјализираме добиеното знаење.

Нептун поддржува влезни оператори преку SPARQL барања, и сурови и базирани на примероци. Подолу ќе разговараме за двата пристапа.

Една од нашите цели беше да внесуваме податоци на стриминг начин. Размислете за издавање албум во нова земја. Од перспектива на MusicBrainz, тоа значи дека за издание кое вклучува албуми, синглови, EP итн., се додава нов запис на табелата ослободување-земја. Во RDF, ги поклопуваме овие информации со две нови тројки.

INSERT DATA { <http://musicbrainz.foo/release-country/737041> <http://musicbrainz.foo/release> <http://musicbrainz.foo/release/435759> };INSERT DATA { <http://musicbrainz.foo/release-country/737041> <http://musicbrainz.foo/date-year> "2018"^^<http://www.w3.org/2001/XMLSchema#int> };

Друга цел беше да се добие ново знаење од графиконот. Да речеме дека сакаме да го добиеме бројот на изданија што секој уметник ги има објавено во својата кариера. Таквото барање е доста сложено и трае повеќе од 20 минути во Нептун, така што треба да го материјализираме резултатот со цел повторно да го искористиме ова ново знаење во некое друго барање. Така, додаваме тројки со оваа информација назад во графикот, внесувајќи го резултатот од подпрашањето.

INSERT {
 
 
  ?artist_credit <http://musicbrainz.foo/number-of-releases> ?number_of_releases
 
} WHERE {
 
  SELECT ?artist_credit (COUNT(*) as ?number_of_releases)
 
  WHERE {
 
     ?artist_credit <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist-credit> .
 
     ?release_group <http://musicbrainz.foo/artist-credit> ?artist_credit .
 
     ?release_group <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/release-group> .
 
     ?release_group <http://musicbrainz.foo/name> ?release_group_name .
 
  }
 
  GROUP BY ?artist_credit
 
}

Додавањето единечни тројки на графикот трае неколку милисекунди, додека времето на извршување за вметнување резултат на подпрашање зависи од времето на извршување на самото подпрашање.

Иако не го користевме често, Нептун исто така ви дозволува да отстраните тројки врз основа на примероци или експлицитни податоци, кои може да се користат за ажурирање информации.

SPARQL прашања

Со воведување на претходниот потпримерок, кој го враќа бројот на изданија за секој изведувач, веќе го воведовме првиот тип на барање што сакаме да го одговориме со помош на Нептун. Изградбата на барање во Нептун е лесно - испратете барање POST до крајната точка SPARQL, како што е прикажано подолу:

curl -X POST --data-binary 'query=SELECT ?artist ?p ?o where {?artist <http://musicbrainz.foo/name> "Elton John" . ?artist ?p ?o . }' http://your-neptune-cluster:8182/sparql

Дополнително, имплементиравме барање кое враќа профил на изведувач кој содржи информации за неговото име, возраст или земја на потекло. Имајте на ум дека изведувачите може да бидат поединци, бендови или оркестри. Дополнително, ги дополнуваме овие податоци со информации за бројот на изданија објавени од уметници во текот на годината. За соло уметници, додаваме и информации за бендовите во кои уметникот учествувал секоја година.

SELECT
 
 
 ?artist_name ?year
 
 ?releases_in_year ?releases_up_year
 
 ?artist_type_name ?releases
 
 ?artist_gender ?artist_country_name
 
 ?artist_begin_date ?bands
 
 ?bands_in_year
 
WHERE {
 
 # Bands for each artist
 
 {
 
   SELECT
 
     ?year
 
     ?first_artist
 
     (group_concat(DISTINCT ?second_artist_name;separator=",") as ?bands)
 
     (COUNT(DISTINCT ?second_artist_name) AS ?bands_in_year)     
 
   WHERE {
 
     VALUES ?year {
 
       1960 1961 1962 1963 1964 1965 1966 1967 1968 1969
 
       1970 1971 1972 1973 1974 1975 1976 1977 1978 1979
 
       1980 1981 1982 1983 1984 1985 1986 1987 1988 1989
 
       1990 1991 1992 1993 1994 1995 1996 1997 1998 1999
 
       2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
 
       2010 2011 2012 2013 2014 2015 2016 2017 2018
 
     }   
 
     ?first_artist <http://musicbrainz.foo/name> "Elton John" .
 
     ?first_artist <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist> .
 
     ?first_artist <http://musicbrainz.foo/type> ?first_artist_type .
 
     ?first_artist <http://musicbrainz.foo/name> ?first_artist_name .
 

 
 
     ?second_artist <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist> .
 
     ?second_artist <http://musicbrainz.foo/type> ?second_artist_type .
 
     ?second_artist <http://musicbrainz.foo/name> ?second_artist_name .
 
     optional { ?second_artist <http://musicbrainz.foo/begin-date-year> ?second_artist_begin_date_year . }
 
     optional { ?second_artist <http://musicbrainz.foo/end-date-year> ?second_artist_end_date_year . }
 

 
 
     ?l_artist_artist <http://musicbrainz.foo/entity0> ?first_artist .
 
     ?l_artist_artist <http://musicbrainz.foo/entity1> ?second_artist .
 
     ?l_artist_artist <http://musicbrainz.foo/link> ?link .
 

 
 
     optional { ?link <http://musicbrainz.foo/begin-date-year> ?link_begin_date_year . }
 
     optional { ?link <http://musicbrainz.foo/end-date-year> ?link_end_date_year . }
 

 
 
     FILTER (!bound(?link_begin_date_year) || ?link_begin_date_year <= ?year)
 
     FILTER (!bound(?link_end_date_year) || ?link_end_date_year >= ?year)
 
     FILTER (!bound(?second_artist_begin_date_year) || ?second_artist_begin_date_year <= ?year)
 
     FILTER (!bound(?second_artist_end_date_year) || ?second_artist_end_date_year >= ?year)
 
     FILTER (?first_artist_type NOT IN (<http://musicbrainz.foo/artist-type/2>, <http://musicbrainz.foo/artist-type/5>, <http://musicbrainz.foo/artist-type/6>))
 
     FILTER (?second_artist_type IN (<http://musicbrainz.foo/artist-type/2>, <http://musicbrainz.foo/artist-type/5>, <http://musicbrainz.foo/artist-type/6>))
 
   }
 
   GROUP BY ?first_artist ?year
 
 }
 
 # Releases up to a year
 
 {
 
   SELECT
 
     ?artist
 
     ?year
 
     (group_concat(DISTINCT ?release_name;separator=",") as ?releases)
 
     (COUNT(*) as ?releases_up_year)
 
   WHERE {
 
     VALUES ?year {
 
       1960 1961 1962 1963 1964 1965 1966 1967 1968 1969
 
       1970 1971 1972 1973 1974 1975 1976 1977 1978 1979
 
       1980 1981 1982 1983 1984 1985 1986 1987 1988 1989
 
       1990 1991 1992 1993 1994 1995 1996 1997 1998 1999
 
       2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
 
       2010 2011 2012 2013 2014 2015 2016 2017 2018 
 
     }
 

 
 
     ?artist <http://musicbrainz.foo/name> "Elton John" .
 

 
 
     ?artist_credit_name <http://musicbrainz.foo/artist-credit> ?artist_credit .
 
     ?artist_credit_name <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist-credit-name> .
 
     ?artist_credit_name <http://musicbrainz.foo/artist> ?artist .
 
     ?artist_credit <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist-credit> .
 

 
 
     ?release_group <http://musicbrainz.foo/artist-credit> ?artist_credit .
 
     ?release_group <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/release-group> .
 
     ?release_group <http://musicbrainz.foo/name> ?release_group_name .
 
     ?release <http://musicbrainz.foo/release-group> ?release_group .
 
     ?release <http://musicbrainz.foo/name> ?release_name .
 
     ?release_country <http://musicbrainz.foo/release> ?release .
 
     ?release_country <http://musicbrainz.foo/date-year> ?release_country_year .
 

 
 
     FILTER (?release_country_year <= ?year)
 
   }
 
   GROUP BY ?artist ?year
 
 }
 
 # Releases in a year
 
 {
 
   SELECT ?artist ?year (COUNT(*) as ?releases_in_year)
 
   WHERE {
 
     VALUES ?year {
 
       1960 1961 1962 1963 1964 1965 1966 1967 1968 1969
 
       1970 1971 1972 1973 1974 1975 1976 1977 1978 1979
 
       1980 1981 1982 1983 1984 1985 1986 1987 1988 1989
 
       1990 1991 1992 1993 1994 1995 1996 1997 1998 1999
 
       2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
 
       2010 2011 2012 2013 2014 2015 2016 2017 2018 
 
     }
 

 
 
     ?artist <http://musicbrainz.foo/name> "Elton John" .
 

 
 
     ?artist_credit_name <http://musicbrainz.foo/artist-credit> ?artist_credit .
 
     ?artist_credit_name <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist-credit-name> .
 
     ?artist_credit_name <http://musicbrainz.foo/artist> ?artist .
 
     ?artist_credit <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/artist-credit> .
 

 
 
     ?release_group <http://musicbrainz.foo/artist-credit> ?artist_credit .
 
     ?release_group <http://musicbrainz.foo/rdftype> <http://musicbrainz.foo/release-group> .
 
     ?release_group <http://musicbrainz.foo/name> ?release_group_name .
 
     ?release <http://musicbrainz.foo/release-group> ?release_group .
 
     ?release_country <http://musicbrainz.foo/release> ?release .
 
     ?release_country <http://musicbrainz.foo/date-year> ?release_country_year .
 

 
 
     FILTER (?release_country_year = ?year)
 
   }
 
   GROUP BY ?artist ?year
 
 }
 
 # Master data
 
 {
 
   SELECT DISTINCT ?artist ?artist_name ?artist_gender ?artist_begin_date ?artist_country_name
 
   WHERE {
 
     ?artist <http://musicbrainz.foo/name> ?artist_name .
 
     ?artist <http://musicbrainz.foo/name> "Elton John" .
 
     ?artist <http://musicbrainz.foo/gender> ?artist_gender_id .
 
     ?artist_gender_id <http://musicbrainz.foo/name> ?artist_gender .
 
     ?artist <http://musicbrainz.foo/area> ?birth_area .
 
     ?artist <http://musicbrainz.foo/begin-date-year> ?artist_begin_date.
 
     ?birth_area <http://musicbrainz.foo/name> ?artist_country_name .
 

 
 
     FILTER(datatype(?artist_begin_date) = xsd:int)
 
   }

Поради сложеноста на ваквото барање, можевме да извршиме точки за пребарување само за одреден изведувач, како што е Елтон Џон, но не и за сите уметници. Се чини дека Нептун не го оптимизира таквото барање со фрлање филтри во подизбори. Затоа, секој избор мора рачно да се филтрира според името на изведувачот.

Нептун има и час и по I/O наплата. За нашето тестирање, го користевме минималниот пример на Нептун, кој чини 0,384 долари/час. Во случајот со горенаведеното барање, кое го пресметува профилот за еден работник, Амазон ни наплатува десетици илјади операции на влез/излез, што подразбира цена од 0.02 долари.

Излез

Прво, Амазон Нептун ги исполнува повеќето од своите ветувања. Како управувана услуга, таа е база на податоци за графикони што е исклучително лесна за инсталирање и може да биде отворена и да работи без многу конфигурации. Еве ги нашите пет клучни наоди:

• Масовното поставување е лесно, но бавно. Но, може да се искомплицира со пораки за грешка кои не се многу корисни.
• Преземањето стриминг поддржува се што очекувавме и беше доста брзо
• Барањата се едноставни, но не доволно интерактивни за да се извршат аналитички прашања
• SPARQL барањата мора да се оптимизираат рачно
• Плаќањата на Амазон е тешко да се проценат бидејќи е тешко да се процени количината на податоци скенирани со барање SPARQL.

Тоа е се. Пријави се за бесплатен вебинар на тема „Load Balancing“.


Извор: www.habr.com