Amazon RDS G / Ç istekleri - 1 sorgu = 1 faturalandırılabilir G / Ç?


9

Amazon RDS'ye geçirmek istediğim bir InnoDB veritabanım var.

Kendi sunucumda barındırılan mevcut uygulamam ayda yaklaşık 8 milyon sorgu gösteriyor.

RDS sitesi G / Ç Oranının 1 milyon istek başına 0,10 ABD doları olduğunu söylüyor

1 G / Ç = 1 sorgulama yapar mı? yani, bu kullanım miktarı + RDS ücretleri için ayda 80 ABD doları faturalandırılacak mıyım?

Yanıtlar:


7

UYARI: Sayılarınıza ve Sorgu olarak görüntülediklerinize çok dikkat edin !!!

Neden böyle bir uyarı veriyorum ???

Ağustos 2011'de ServerFault'ta 24 gün içinde 1 Milyar Sorgunun nasıl yürütülebileceğini açıklayan bir yazı yazdım .

İşte tüm yazı:

MySQL, sorguları dahili olarak arayacaktır. Aslında, MySQL'de yaptığınız hemen hemen her şey bir sorgudur.

Genel günlüğü veya yavaş sorgu günlüğünü açarsanız, mysqld'in yaptığı her şey kaydedilir.

Eğer varsa --log-sorguları--dizinleri kullanmayan her şey yavaş günlüğüne endeksler toprakları kapsayan değil, etkin.

Diyelim ki bu sorguyu çalıştırıyorsunuz:

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| annarbor           |
| dude               |
| example            |
| garbage            |
| lovesh             |
| mysql              |
| performance_schema |
| replagdb           |
| stuff              |
| test               |
| tostinni           |
| wordpress          |
| zipcodes           |
+--------------------+
14 rows in set (0.06 sec)

Evet, VERİTABANLARI GÖSTER; bir sorgudur. Aslında, info_schema eşdeğeri ne ???

mysql> select schema_name "Database" from information_schema.schemata;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| annarbor           |
| dude               |
| example            |
| garbage            |
| lovesh             |
| mysql              |
| performance_schema |
| replagdb           |
| stuff              |
| test               |
| tostinni           |
| wordpress          |
| zipcodes           |
+--------------------+
14 rows in set (0.08 sec)

İnformation_schema.schemata tablosunun bir dizini var mı ???

mysql> show create table information_schema.schemata\G
*************************** 1. row ***************************
       Table: SCHEMATA
Create Table: CREATE TEMPORARY TABLE `SCHEMATA` (
  `CATALOG_NAME` varchar(512) NOT NULL DEFAULT '',
  `SCHEMA_NAME` varchar(64) NOT NULL DEFAULT '',
  `DEFAULT_CHARACTER_SET_NAME` varchar(32) NOT NULL DEFAULT '',
  `DEFAULT_COLLATION_NAME` varchar(32) NOT NULL DEFAULT '',
  `SQL_PATH` varchar(512) DEFAULT NULL
) ENGINE=MEMORY DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Hayır. DATABAZLARI GÖSTER; genel bir günlüğe ve yavaş günlüğe iner (--log-sorguları -kullanmayan-dizinler etkinken)

Bu nedenle, bir sorgu oluşturacağını düşünmediğimiz birçok işlem sadece bir sorgu olabilir, ancak mysqld için dahili olabilir.

Mysqld'e bağlı herhangi bir izleme aracı kullanıyorsanız, bu sorgulardaki sayıları da azaltır.

Misal:

mysql> show global status like 'uptime'; select * from information_schema.global_status where variable_name='uptime';

+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 613   |
+---------------+-------+
1 row in set (0.00 sec)

+---------------+----------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+---------------+----------------+
| UPTIME        | 613            |
+---------------+----------------+
1 row in set (0.00 sec)

Sadece mysqld'in çalışma süresini almak bir sorgudur. Dahili olarak, MySQL yürütülen sorguları nasıl sayar? İşte biraz ışık tutabilecek iki durum değişkeni:

  • Sorgular : Sunucu tarafından yürütülen deyimlerin sayısı. Bu değişken, Sorular değişkeninden farklı olarak, saklanan programlar içinde yürütülen ifadeleri içerir. COM_PING veya COM_STATISTICS komutlarını saymaz.

  • Sorular : Sunucu tarafından yürütülen ifade sayısı. Bu, sorgular değişkeninin aksine, yalnızca istemciler tarafından sunucuya gönderilen deyimleri içerir, depolanan programlar içinde yürütülen deyimleri içermez. Bu değişken COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE veya COM_STMT_RESET komutlarını saymaz.

Durum değişkenlerini çağıran izleme, istenen verileri almak için dahili olarak sorgular çalıştırdığından, MySQL Sunucunuz izleniyorsa lütfen endişelenmeyin.

24 günde 1 milyar

  • Günde 41,7 milyon sorgu
  • Saatte 1.736 milyon sorgu
  • Dakikada 28.935 sorgu
  • Saniyede 482 sorgu

İzlenmekte olan bir MySQL örneği için, bu sayılar hiç ileri getirilmez.

MySQL Workbench, MySQL Administrator veya phpMyAdmin kullanıyorsanız, bu ürünlerin oluşturduğu veya güncellediği sayfalar bu küçük durum sorgularını toplar ve sayıları hızlı bir şekilde çalıştırır.

ÖZET

Siteniz gerçekten 8 milyon sorgu yapıyorsa, 1 milyon istek başına G / Ç Oranı 0,10 ABD doları, ayda 0,80 ABD doları (80 sent) olmalıdır. Ayda 1 Milyar sorgu yürütürseniz 100,00 dolar olur. Lütfen bu numaraların jive olduğundan emin olun ve SİZİN SONRAKİ CFO OTURUMUNUZLA YAZMAK İÇİN ALIN !!!

GÜNCELLEME 2012-05-02 16:26 EDT

Ayda 800 milyon sorgu olduğu için ayda 80,00 dolar


1
Cevabınız için teşekkürler ... Ben 8M değil, 800M yazmak istedim. Ne olursa olsun, 1 sorgu = 1 G / Ç olup olmadığını biliyor musunuz?

İlgili sorumu burada yanıtlayabilirseniz harika olurdu: dba.stackexchange.com/questions/49869/…
Upvote

6

Hayır, bir G / Ç işlemi bir sorguya eşit değildir. Bir sorgu, sorgu önbelleği tarafından işlenirse (ve şanslıysanız) 0 IO işlemiyle sonuçlanabilir veya birden çok IO işlemiyle sonuçlanabilir. Potansiyel olarak, yüzlerce ve binlerce, sanırım, tablolara, dizinlere, sorgulara ve diğer ayrıntılara bağlı olarak.

http://aws.amazon.com/ebs/ aşağıdakileri belirtir:

Standart birimler için birim depolama alanı, siz onu serbest bırakana kadar her ay GB cinsinden sağladığınız miktarla ücretlendirilir. Standart birimler için Birim G / Ç, biriminize yaptığınız istek sayısı ile ücretlendirilir. IOSTAT gibi programlar, sisteminizin tam I / O kullanımını her zaman ölçmek için kullanılabilir. Bununla birlikte, uygulamalar ve işletim sistemleri genellikle farklı düzeylerde önbellekleme yapar, bu nedenle Standart birimler için, tüm G / Ç'lerinizi diske senkronize etmedikçe, faturanızda muhtemelen uygulamanızın göründüğünden daha az sayıda G / Ç isteği görürsünüz. .

iostat, veritabanı sorguları hakkında hiçbir şey bilmeyen düşük düzeyli bir linux yardımcı programıdır. http://linux.die.net/man/1/iostat

Yukarıdaki alıntı EBS hizmeti içindir, ancak RDS EC2 ve EBS'ye dayanmaktadır, bu yüzden RDS'de aynı şeyi ifade ettiklerinden oldukça eminim.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.