Първи впечатления от Amazon Neptune

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

В много случаи на употреба, които харесваме bakdataКакто виждаме на уебсайтовете на нашите клиенти, съответната информация е скрита във връзките между обекти, например при анализиране на връзки между потребители, зависимости между елементи или връзки между сензори. Такива случаи на употреба обикновено се моделират върху графика. По-рано тази година Amazon пусна новата си база данни с графики, Neptune. В тази публикация искаме да споделим нашите първи идеи, добри практики и какво може да се подобри с времето.

Защо се нуждаехме от Amazon Neptune

Графичните бази данни обещават да обработват силно свързани набори от данни по-добре от техните релационни еквиваленти. В такива набори от данни съответната информация обикновено се съхранява във връзки между обекти. Използвахме невероятен проект с отворени данни, за да тестваме Neptune MusicBrainz. MusicBrainz събира всякакъв вид музикални метаданни, които можете да си представите, като информация за изпълнители, песни, издания на албуми или концерти, както и с кого е сътрудничил изпълнителят зад песента или кога албумът е издаден в коя държава. MusicBrainz може да се разглежда като огромна мрежа от субекти, които по някакъв начин са свързани с музикалната индустрия.

Наборът от данни на MusicBrainz се предоставя като CSV дъмп на релационна база данни. Общо дъмпът съдържа около 93 милиона реда в 157 таблици. Докато някои от тези таблици съдържат основни данни като изпълнители, събития, записи, издания или песни, други таблици за връзки — съхранява връзки между изпълнители и записи, други изпълнители или издания и т.н... Те демонстрират графичната структура на набор от данни. При преобразуването на набора от данни в RDF тройки получихме приблизително 500 милиона екземпляра.

Въз основа на опита и впечатленията на партньорите по проекта, с които работим, представяме обстановка, в която тази база от знания се използва за получаване на нова информация. Освен това очакваме да се актуализира редовно, например чрез добавяне на нови версии или актуализиране на членове на групата.

регулиране

Както се очакваше, инсталирането на Amazon Neptune е лесно. Тя е доста подробна документиран. Можете да стартирате база данни с графики само с няколко кликвания. Въпреки това, когато става въпрос за по-подробна конфигурация, необходимата информация трудно за намиране. Следователно искаме да посочим един конфигурационен параметър.

Екранна снимка на конфигурация за групи параметри

Amazon казва, че Neptune се фокусира върху транзакционни натоварвания с ниска латентност, поради което времето за изчакване на заявката по подразбиране е 120 секунди. Ние обаче тествахме много случаи на аналитична употреба, в които редовно достигахме това ограничение. Това изчакване може да бъде променено чрез създаване на нова група параметри за Neptune и настройка neptune_query_timeout съответното ограничение.

Зареждане на данни

По-долу ще обсъдим подробно как заредихме данни от MusicBrainz в Neptune.

Връзки в тройки

Първо преобразувахме данните от 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> .

групово качване

Предложеният начин за зареждане на големи количества данни в Neptune е чрез процеса на групово качване чрез 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"
 
}'

За да избегнем този дълъг процес всеки път, когато стартираме Neptune, решихме да възстановим екземпляра от моментна снимка, в която тези триплети вече бяха заредени. Изпълнението от моментна снимка е значително по-бързо, но все пак отнема около час, докато Neptune стане достъпен за заявки.

При първоначалното зареждане на тризнаци в Neptune се натъкнахме на различни грешки.

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

Някои от тях бяха грешки при синтактичния анализ, както е показано по-горе. Към днешна дата все още не сме разбрали какво точно се е объркало в този момент. Малко повече подробности определено биха помогнали тук. Тази грешка възникна за приблизително 1% от вмъкнатите тройки. Но що се отнася до тестването на Neptune, ние приехме факта, че работим само с 99% от информацията от MusicBrainz.

Въпреки че това е лесно за хората, запознати със SPARQL, имайте предвид, че RDF тройките трябва да бъдат анотирани с изрични типове данни, което отново може да причини грешки.

Поточно изтегляне

Както бе споменато по-горе, ние не искаме да използваме Neptune като статично хранилище на данни, а по-скоро като гъвкава и развиваща се база от знания. Така че трябваше да намерим начини да въведем нови тройки, когато базата от знания се промени, например когато се публикува нов албум или когато искаме да материализираме полученото знание.

Neptune поддържа оператори за въвеждане чрез 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 минути в Neptune, така че трябва да материализираме резултата, за да използваме повторно тези нови знания в друга заявка. Така че добавяме тройки с тази информация обратно към графиката, въвеждайки резултата от подзаявката.

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
 
}

Добавянето на единични тройки към графиката отнема няколко милисекунди, докато времето за изпълнение за вмъкване на резултата от подзаявка зависи от времето за изпълнение на самата подзаявка.

Въпреки че не го използвахме често, Neptune също ви позволява да премахвате тризнаци въз основа на проби или изрични данни, които могат да се използват за актуализиране на информация.

SPARQL заявки

С въвеждането на предишната подизвадка, която връща броя на изданията за всеки изпълнител, ние вече въведохме първия тип заявка, на която искаме да отговорим, използвайки Neptune. Създаването на заявка в Neptune е лесно - изпратете 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)
 
   }

Поради сложността на такава заявка, бихме могли да извършим заявки за точки само за конкретен изпълнител, като Елтън Джон, но не и за всички изпълнители. Neptune изглежда не оптимизира такава заявка чрез пускане на филтри в подизбори. Следователно всяка селекция трябва да бъде ръчно филтрирана по име на изпълнител.

Neptune има както почасови, така и I/O такси. За нашето тестване използвахме минималния екземпляр на Neptune, който струва $0,384/час. В случая на заявката по-горе, която изчислява профила за един работник, Amazon ни таксува десетки хиляди I/O операции, което предполага цена от $0.02.

Продукция

Първо, Amazon Neptune спазва повечето от обещанията си. Като управлявана услуга, това е графична база данни, която е изключително лесна за инсталиране и може да работи без много конфигурация. Ето нашите пет ключови констатации:

• Груповото качване е лесно, но бавно. Но може да се усложни със съобщения за грешка, които не са много полезни.
• Поточно изтегляне поддържа всичко, което очаквахме, и беше доста бързо
• Заявките са прости, но не достатъчно интерактивни, за да изпълняват аналитични заявки
• SPARQL заявките трябва да се оптимизират ръчно
• Плащанията на Amazon са трудни за оценка, тъй като е трудно да се оцени количеството данни, сканирани от SPARQL заявка.

Това е всичко. Запиши се за безплатен уебинар на тема „Балансиране на натоварването“.


Източник: www.habr.com