从S3加载数据 - 大数据和索引的最快方式

问题描述 投票：0回答：1

我有一个由假期交易组成的表，所以为了给你一个想法，每一行将包含以下数据：

Departure airport
Arrival airport
Start date
Duration
Hotel destination
Resort
Hotel name
Hotel rating
A few tiny integer columns for 1s and 0s.
Price
Date time the row was updated

现在，所有这些交易都从3个表中打包，它们是flights，accommodation和transfers，包装是为每个变化找到最便宜的交易，例如，每个出发机场，持续时间，董事会基础等。

我导入的表将包含大约5000万行，导入速度非常慢。

我已经删除了索引，这产生了巨大的差异，但现在当我在所有数据都在那里之后重新添加索引回到表中时，它需要永远完成。

我想知道有没有一种方法可以快速批量加载数据，还是有一种更快的方法可以在添加数据后将索引添加回表中？

创建表

```

    CREATE TABLE `iv_deals` (
    `aid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Deal Autonumber PK',
    `startdate` DATE NULL DEFAULT NULL COMMENT 'Holiday Start Date',
    `startdatet` TINYINT(2) NOT NULL DEFAULT '0',
    `depairport` CHAR(3) NULL DEFAULT NULL COMMENT 'Departure Airport IATA Code',
    `arrairport` CHAR(3) NULL DEFAULT NULL COMMENT 'Arrival Airport IATA Code',
    `destination` VARCHAR(30) NULL DEFAULT NULL COMMENT 'Holiday Destination',
    `resort` VARCHAR(30) NULL DEFAULT NULL COMMENT 'Holiday Resort',
    `hotel` VARCHAR(50) NULL DEFAULT NULL COMMENT 'Holiday Property Name',
    `iv_PropertyID` INT(11) UNSIGNED NOT NULL DEFAULT '0' COMMENT 'Holiday Property ID',
    `rating` VARCHAR(2) NULL DEFAULT NULL COMMENT 'Holiday Property Star Rating',
    `board` VARCHAR(10) NULL DEFAULT NULL COMMENT 'Holiday Meal Option',
    `duration` TINYINT(2) UNSIGNED NULL DEFAULT '0' COMMENT 'Holiday Duration',
    `2for1` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Is 2nd Week FREE Offer, 0 = False, 1 = True',
    `3for2` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Is 3rd Week FREE Offer, 0 = False, 1 = True',
    `3and4` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Is 3rd and 4th Week FREE Offer, 0 = False, 1 = True',
    `4for3` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Is 4th Week FREE Offer, 0 = False, 1 = True',
    `freebb` VARCHAR(2) NULL DEFAULT NULL COMMENT 'Free Week Meal Option',
    `adults` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Number of Adults',
    `children` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Number of Children',
    `infants` TINYINT(1) UNSIGNED NULL DEFAULT '0' COMMENT 'Number of Infants',
    `price` SMALLINT(4) UNSIGNED NULL DEFAULT '9999' COMMENT 'Price',
    `carrier` VARCHAR(40) NULL DEFAULT NULL COMMENT 'Flight Carrier IATA Code',
    `DateUpdated` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`aid`, `startdatet`),
    UNIQUE INDEX `Unique` (`startdate`, `depairport`, `arrairport`, `iv_PropertyID`, `board`, `duration`, `adults`, `children`, `startdatet`),
    INDEX `ik_Price` (`price`),
    INDEX `ik_Destination` (`destination`),
    INDEX `ik_Resort` (`resort`),
    INDEX `ik_DepAirport` (`depairport`),
    INDEX `ik_Startdate` (`startdate`),
    INDEX `ik_Board` (`board`),
    INDEX `ik_FILTER_ALL` (`price`, `depairport`, `destination`, `resort`, `board`, `startdate`),
    INDEX `iv_PropertyID` (`iv_PropertyID`),
    INDEX `ik_Duration` (`duration`),
    INDEX `rating` (`rating`),
    INDEX `adults` (`adults`),
    INDEX `DirectFromPrice` (`iv_PropertyID`, `depairport`, `arrairport`, `board`, `duration`, `adults`, `children`, `startdate`),
    INDEX `DirectFromPrice_wo_depairport` (`iv_PropertyID`, `arrairport`, `board`, `duration`, `adults`, `children`),
    INDEX `DirectFromPrice_w_pid_dep` (`iv_PropertyID`, `depairport`, `adults`, `children`, `price`),
    INDEX `DirectFromPrice_w_pid_night` (`iv_PropertyID`, `duration`, `adults`, `children`),
    INDEX `DirectFromPrice_Dur_Board` (`iv_PropertyID`, `duration`, `board`, `adults`, `children`),
    INDEX `join_index` (`destination`, `startdate`, `duration`)
)
COLLATE='utf8_general_ci'
AUTO_INCREMENT=1258378560
/*!50100 PARTITION BY LIST (startdatet)
(PARTITION part0 VALUES IN (1) ENGINE = InnoDB,
 PARTITION part1 VALUES IN (2) ENGINE = InnoDB,
 PARTITION part2 VALUES IN (3) ENGINE = InnoDB,
 PARTITION part3 VALUES IN (4) ENGINE = InnoDB,
 PARTITION part4 VALUES IN (5) ENGINE = InnoDB,
 PARTITION part5 VALUES IN (6) ENGINE = InnoDB,
 PARTITION part6 VALUES IN (7) ENGINE = InnoDB,
 PARTITION part7 VALUES IN (8) ENGINE = InnoDB,
 PARTITION part8 VALUES IN (9) ENGINE = InnoDB,
 PARTITION part9 VALUES IN (10) ENGINE = InnoDB,
 PARTITION part10 VALUES IN (11) ENGINE = InnoDB,
 PARTITION part11 VALUES IN (12) ENGINE = InnoDB,
 PARTITION part12 VALUES IN (0) ENGINE = InnoDB)  */;

```

mysql amazon-s3 bigdata
1个回答
0
投票

如果有50M行，但AUTO_INCREMENT=1258378560，请指出另一个迫在眉睫的问题。 （这可能与缓慢负载有关。）

`aid` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT

仅允许40亿;你已经12亿了。做一些小数学来估计你什么时候会用完ids。蛮力解决方案是改为BIGINT，但让我们分析一下为什么'被烧'。 INSERT / REPLACE / etc有几种方法可以丢弃id。请描述导入是如何工作的。 REPLACE可能是最糟糕的 - 它燃烧的ids，实际上是DELETE + INSERT。其他技术更快。

（我现在会在很多方向漫步......）

按月划分（我假设您正在使用（startdatet）可能不会增加任何性能。您的经验是什么？（我通常反对使用PARTITION，除了少数有利用的用例。我认为没有好处在你的情况下。）

19个索引表示必须更新的19个BTrees。在INSERT完成之前必须检查2个独特的;其他17人可以延迟，但不是永远。 （详情在“更改缓冲区”下讨论。）

内存多少钱？ innodb_buffer_pool_size的设置是什么？它应该是RAM的70％左右。更改缓冲区是其中的一部分。

我看到至少有4个可以删除的索引，因为其他索引可以处理它们的需要。一般来说，如果你有INDEX(a, b)，你也不需要INDEX(a)。 （从19个指数收缩到15指数将有所帮助。）

标志和低基数的其他东西实际上是无用的自己作为索引。优化器将决定扫描表比在索引的BTree和数据BTree之间反弹更便宜。我在想INDEX(rating)。

在SELECT中没有startdatet的任何WHERE可能比没有分区时慢。这是因为查询必须检查所有13个分区。即使使用AND startdatet = 4，性能也不会比包含startdatet的索引更好。

让我讨论以列（可能是price，rating，startdate）开头的任何索引，它被称为“范围”（例如，WHERE price BETWEEN ...）。处理不能使用该列之后的任何列。我怀疑ik_FILTER_ALL将扫描指数的一大部分，因为它只在price上过滤。重新排列列。根据名称，我猜这是一个“覆盖”索引。也就是说，常见查询只引用那6列？注意：SELECT * ...引用的不仅仅是那些6，因此索引不是“覆盖”。 （向我们展示查询;我可以更多地讨论它。）

对于某些查询，5“DirectFromPrice”索引可能都是“完美的”。但它们非常长（很多专栏）。我猜想2个较短的列表将接近处理5个“足够好”的情况。 （请记住，减少索引数量有助于实现插入时间。）

你使用的是什么版本的MySQL / MariaDB？

此时的主要操作项：向我们显示导入。 （我将在看到使用的方法后讨论对输入进行排序。）

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.