Задержка Aurora и DynamoDB не такая, как ожидалось - PullRequest
Новая
       44

Задержка Aurora и DynamoDB не такая, как ожидалось

0 голосов
/ 08 апреля 2019

Я хотел получить несколько цифр, чтобы доказать, что мое хранилище DynamoDB Key-Value имеет лучшую производительность чтения по сравнению с реляционными БД (MySQL, PostgreSQL, Aurora). Поэтому я решил сравнить задержки чтения в DynamoDB и AWS-Aurora (который относится к веб-сайту AWS - «в пять раз быстрее, чем стандартные базы данных MySQL, и в три раза быстрее, чем стандартные базы данных PostgreSQL»)

Step1 : создал таблицу в Aurora со следующей схемой и добавил 1,02 миллиона записей в эту таблицу. 

Table gift_log (
  gift_uuid               BINARY(16) NOT NULL,
  user_uuid               BINARY(16) NOT NULL,
  parent_uuid             BINARY(16),
  operation_time          TIMESTAMP,
  operation               VARCHAR(20) NOT NULL,
  gift_type               VARCHAR(20) NOT NULL,
  parent_type             VARCHAR(20),
  relation_type           VARCHAR(20),
  PRIMARY KEY (gift_uuid)
);

Используется клиент Golang, который использует драйвер MySQL для базы данных / пакет sql для запроса таблицы.

Step2 ; Создана таблица DynamoDB со следующими Атрибутами. Добавил 1 миллион предметов на стол. НЕ использовал любой ключ сортировки. Во всех запросах используется ключ раздела. 


Table: GiftLog {
    gift_uuid               Binary (Partition Key)
    user_uuid               Binary
    operation_time          Number,
    operation               String,
    gift_type               String,
    parent_type             String
}

Использовал Golang Client, который использует AWS Go-SDK для запроса таблицы DynamoDB.

AURORA 

startTime := time.Now().UnixNano()

rows, err := db.Query("SELECT * FROM gift_log WHERE gift_uuid=?", giftIDsToRead[i])

endTimt := time.Now().UnixNano()

DynamoDB 

queryInput := &dynamodb.QueryInput{
        TableName: aws.String(tableName),
        KeyConditions: map[string]*dynamodb.Condition{
                        "GiftUUID": {
                            ComparisonOperator: aws.String("EQ"),
                            AttributeValueList: []*dynamodb.AttributeValue{
                                {
                                    B: giftIDsToRead[i],
                                },
                            },
                        },
        },
}

startTime := time.Now().UnixNano()

resp, err := svc.Query(queryInput)

endTime := time.Now().UnixNano()

Задержка Aurora: 543,89 Задержка DynamoDB: 2934,96 usec

Эти цифры не кажутся правильными. Я не сравниваю яблоки с яблоками?

Ответы [ 2 ]

2 голосов
/ 09 апреля 2019

Вы не показываете результаты времени ... но я бы сказал, что вы сравниваете яблоки с апельсинами. Если вы знаете первичный ключ элемента DynamoDB, вам следует использовать GetItem () , а не Query ().

Используя GetItem (), вы должны иметь время отклика "одна цифра миллисекунды"; без учета задержки сети / HTTP

Этот последний бит важен, но мы надеемся, что он будет похож на запросы Авроры.

0 голосов
/ 09 апреля 2019

Я думаю, вам не хватает нескольких очень важных моментов.

  1. DynamoDB - это «база данных как услуга», тогда как Aurora - более традиционная база данных
  2. Всякий раз, когда вы проводите тест производительности или любой другой вид, вы не можете просто запустить один тест: вам нужно выполнить лоты, а затем вычислить статистику, такую ​​как среднее или, что еще лучше, верхний процентиль (скажем, 99-й процентиль)
  3. DynamoDB светит, когда вам нужна «предсказуемая производительность в любом масштабе»

Первый пункт важен, потому что он означает, что для получения данных из DynamoDB вы делаете веб-запросы, которые имеют некоторую степень издержек по сравнению с более традиционной базой данных. Эти издержки вполне могут составлять порядка 1-2 миллисекунд на запрос. Но, по-видимому, это нормально в контексте большинства приложений, если приложение хорошо спроектировано и не выполняет тонну ненужных запросов.

Второй момент важен, потому что, если вы не посмотрите на него правильно, вы можете измерить выбросы: это означает, что вы можете увидеть некоторые результаты, которые не отражают типичную производительность и могут потратить много времени в погоне за красными сельдями. Вместо того, чтобы измерять производительность одного запроса, измерьте производительность многих запросов того же типа и вычислите некоторые показатели, такие как: среднее значение и стандартное отклонение; или N-й процентиль (типично 50-е, 90-е, 99-е)

Последнее замечание действительно мотивирует использование DynamoDB по сравнению с классическим механизмом базы данных. Вы смотрите на самый счастливый из счастливых случаев: (предположительно) небольшую таблицу с несколькими элементами, где вы извлекаете одну таблицу, используя ее первичный ключ. DynamoDB - это все, что происходит, когда ваши данные со временем растут Вы хотите иметь такую ​​же производительность при получении этого элемента сейчас, когда ваша таблица содержит 1000 элементов, как и когда ваша таблица содержит 100 000 000 элементов. И с более сложными запросами все становится интереснее.

С DynamoDB вы торгуете с небольшим снижением производительности в самых простых случаях для стабильности.

Но DynamoDB - это не панацея! Бывают ситуации, когда реляционная база данных всегда побеждает DynamoDB.

...