database - porque - ¿Cuáles son las implicaciones del uso de SSD en los supuestos fundamentales de la base de datos?

porque se daña un disco ssd

Question

Los SSD son comunes ahora; Amazon EBS está respaldado por SSD y, por lo tanto, la mayoría de las bases de datos en la nube ahora también se ejecutan en SSD (Heroku PostgreSQL, etc.). Las bases de datos y las arquitecturas relacionadas se diseñaron tradicionalmente con la idea de que el acceso aleatorio es malo; este ya no es el caso de los SSD.

¿Cómo efectúan los SSD lo siguiente?

1. Diseño de base de datos: los DB están diseñados para minimizar las búsquedas de discos (WAL, B-trees). ¿Cómo cambian los SSD los elementos internos y la optimización de un diseño de base de datos?
2. Desarrollo de aplicaciones: el supuesto de trabajo siempre ha sido que (a) desea que los usuarios del servidor soliciten desde la memoria, no DB, y (2) que el acceso a DB esté vinculado a IO. Con los SSD, la recuperación de datos de la base de datos puede ser lo suficientemente rápida, y el acceso a la base de datos a menudo está vinculado a la red. ¿Esto reduce la necesidad de bases de datos en memoria? Obviamente, todavía desea realizar operaciones costosas de cálculo previo, pero potencialmente puede almacenarlas en una base de datos
3. Bases de datos especializadas: hay bastantes bases de datos que hacen cosas en las que se supone que las bases de datos relacionales son malas (en parte debido al acceso aleatorio a los datos). Un ejemplo de ello son los DB de gráficos (Neo4j) que almacenan nodos y listas de adyacencia en el disco de forma compacta. ¿Son estas bases de datos tan útiles si podemos implementar un RDBMS en SSD y no preocuparnos por el acceso aleatorio?

Answer 1

Primero, los SSD no hacen que el acceso aleatorio sea gratuito. Simplemente más barato. En particular, las escrituras aleatorias siguen siendo muy caras, aunque esto se mitiga en escrituras aleatorias pequeñas por un caché de escritura duradera.

WAL sería muy costoso para los SSD si el SSD realmente lo transfiriera a los medios subyacentes, pero no lo hace. Lo acumula en el caché de escritura y lo vacía periódicamente en trozos de tamaño de bloque de borrado. Así que WAL realmente funciona realmente bien en SDDs, ya que nunca hay necesidad de un ciclo de lectura / modificación / escritura para una escritura de bloque de borrado parcial.

Estoy seguro de que hay oportunidades en el almacenamiento de la estructura de árbol para los índices en las SSD. Eso no es algo que realmente hayamos explorado en PostgreSQL todavía.

La mayoría de los servidores de base de datos basados ​​en SSD con los que trabajo siguen siendo totalmente de E / S de disco para el funcionamiento normal. Los SSD son rápidos, pero no mágicos. Incluso los SSD integrados PCI-E no pueden competir con la RAM, y las grandes cargas de trabajo tienden a saturar rápidamente la memoria caché y las colas de respuesta del SSD.

De manera similar, recorrer una lista de adyacencias en un RDBMS aún está lejos de ser gratuito en términos computacionales, la representación en el disco es menos compacta que en una base de datos de gráficos, etc. Hay mucho que ganar de la especialización donde la necesita.

Para ver realmente lo que el almacenamiento ultrarrápido hace con las bases de datos, debe ir un paso más allá y observar los dispositivos de almacenamiento basados ​​en RAM PCIe que son increíblemente rápidos.

Por cierto, de muchas maneras, un SSD no es tan diferente a un HBA SCSI con un gran caché de escritura respaldado por batería. Estos han estado alrededor por mucho tiempo. Un SSD tenderá a tener mejores lecturas aleatorias, pero por lo demás es bastante similar.