Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Escolher entre armazenamento SSD e HDD
Ao criar uma instância do Bigtable, você escolhe se os clusters dela armazenam dados em unidades de estado sólido (SSD) ou unidades de disco rígido (HDD):
O armazenamento SSD é a escolha mais eficiente e rentável para a maioria dos casos de uso.
Às vezes, o armazenamento HDD é apropriado para grandes conjuntos de dados que
não são sensíveis à latência ou são acessados com pouca frequência.
Independentemente do tipo de armazenamento que você escolher, os dados serão armazenados em um sistema de arquivos distribuído e replicado que se estende por muitas unidades físicas.
As diretrizes desta página podem ajudar você a escolher entre SSD e HDD.
Na dúvida, escolha o armazenamento SSD
Há vários motivos pelo qual é melhor usar o armazenamento SSD para seu
cluster do Bigtable:
O SSD é significativamente mais rápido e tem um desempenho mais previsível do que o HDD.
Em um cluster do Bigtable, o armazenamento SSD oferece latências significativamente
menores para leituras e gravações do que o armazenamento HDD.
A capacidade do HDD é muito mais limitada que a do SSD. Em um cluster que
usa o armazenamento HDD, é possível atingir a capacidade máxima antes que
o uso da CPU atinja 100%. É possível monitorar esta situação usando a métrica de carregamento de disco. Para aumentar a capacidade, é preciso adicionar mais nós, mas
o custo de nós adicionais pode facilmente estourar seu orçamento ao usar o armazenamento
HDD. O armazenamento SSD não tem essa limitação, porque oferece muito mais capacidade por nó. Geralmente, um cluster que usa armazenamento SSD atinge o máximo da capacidade somente quando está usando toda a CPU e memória disponíveis.
As leituras de linhas individuais no HDD são muito lentas. Devido ao tempo de busca do disco, o armazenamento do HDD
é compatível apenas com 5% das linhas lidas por segundo de armazenamento SSD. No entanto, grandes verificações em várias linhas não são tão prejudicadas.
A economia de custos com HDD é mínima em relação ao custo dos nós no
cluster do Bigtable, a menos que você esteja armazenando quantidades grandes de
dados. Por isso, como regra geral, não use o armazenamento HDD,
a menos que você armazene pelo menos 10 TB de dados, e a carga de trabalho não seja
sensível à latência.
Uma possível desvantagem do armazenamento SSD é que ele exige mais nodes nos clusters com base nos dados armazenados. Porém, na prática, talvez você precise de nodes extras. Dessa maneira, os clusters podem acompanhar o tráfego de entrada e não servirão apenas para dar suporte ao volume de dados que está armazenando.
Casos de uso de armazenamento HDD
O armazenamento HDD é adequado para casos de uso que atendem a todos estes critérios:
Você espera armazenar pelo menos 10 TB de dados.
Você não usará os dados para auxiliar um aplicativo voltado para o usuário ou sensível à latência.
A carga de trabalho fica em uma das seguintes categorias:
Cargas de trabalho em lote com verificações e gravações, com leituras
aleatórias de um pequeno número de leituras de linhas ou pontos.
Arquivamento de dados, em que você grava grandes volumes de dados e raramente os lê.
Por exemplo, caso você pretenda armazenar dados históricos extensos para um grande número de dispositivos de detecção remota e use os dados para gerar relatórios diários, a economia no armazenamento HDD pode justificar a implicação no desempenho. Por
outro lado, se você planeja usar os dados para exibir um painel em tempo real,
provavelmente não faria sentido usar o armazenamento HDD, porque as leituras seriam muito mais
frequentes neste caso, e as leituras que não são verificações são muito mais lentas
com armazenamento HDD.
Troca entre armazenamento SSD e HDD
Quando você cria uma instância do Bigtable, a escolha de
armazenamento SSD ou HDD para a instância é permanente. Não é possível usar o
consoleGoogle Cloud para mudar o tipo de armazenamento usado para a instância.
Para alterar o tipo de armazenamento da tabela, use o
recurso de backups:
Crie ou planeje usar uma instância que use o tipo de armazenamento desejado.
Crie um backup da tabela.
Faça a restauração do backup para uma nova tabela na outra instância.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-27 UTC."],[[["\u003cp\u003eSSD storage is generally the preferred choice for Bigtable instances due to its superior speed, performance predictability, and higher throughput compared to HDD.\u003c/p\u003e\n"],["\u003cp\u003eHDD storage can be suitable for large datasets (at least 10 TB) that are not latency-sensitive and are infrequently accessed, such as for batch workloads or data archival.\u003c/p\u003e\n"],["\u003cp\u003eThe cost savings of using HDD storage might be minimal when considering the overall cost of nodes in a Bigtable cluster, making SSD storage a better value in most cases.\u003c/p\u003e\n"],["\u003cp\u003eChoosing between SSD and HDD storage is permanent for a Bigtable instance; switching storage types requires using the backup and restore process to move data to a new instance.\u003c/p\u003e\n"],["\u003cp\u003eHDD storage has significantly slower individual row read performance compared to SSD, making it less suitable for applications requiring frequent or real-time data retrieval.\u003c/p\u003e\n"]]],[],null,["# Choose between SSD and HDD storage\n==================================\n\nWhen you create a Bigtable instance, you choose whether its clusters\nstore data on solid-state drives (SSD) or hard disk drives (HDD):\n\n- SSD storage is the most efficient and cost-effective choice for most use cases.\n- HDD storage is sometimes appropriate for large datasets that are not latency-sensitive or are infrequently accessed.\n\nRegardless of which type of storage you choose, your data is stored on a\ndistributed, replicated file system that spans across many physical drives.\n\nThe guidelines on this page can help you choose between SSD and HDD.\n\nWhen in doubt, choose SSD storage\n---------------------------------\n\nThere are several reasons why it's usually best to use SSD storage for your\nBigtable cluster:\n\n- **SSD is significantly faster and has more predictable performance than HDD.** In a Bigtable cluster, SSD storage delivers significantly lower latencies for both reads and writes than HDD storage.\n- **HDD throughput is much more limited than SSD throughput.** In a cluster that uses HDD storage, it's possible to reach the maximum throughput before CPU usage reaches 100%, a situation you can monitor using the [disk load](/bigtable/docs/monitoring-instance#disk) metric. To increase throughput, you must add more nodes, but the cost of the additional nodes might exceed your savings from using HDD storage. SSD storage does not have this limitation, because it offers much more throughput per node---generally, a cluster that uses SSD storage reaches maximum throughput only when it is using all available CPU and memory.\n- **Individual row reads on HDD are very slow.** Because of disk seek time, HDD storage supports only 5% of the read rows per second of SSD storage. Large multi-row scans, however, are not as adversely impacted.\n- **The cost savings from HDD are minimal, relative to the cost of the nodes in\n your Bigtable cluster, unless you're storing large amounts of\n data.** For this reason, as a rule of thumb, you shouldn't consider using HDD storage unless you're storing at least 10 TB of data and your workload is not latency-sensitive.\n\nOne potential drawback of SSD storage is that it [requires more nodes in your\nclusters](/bigtable/quotas#storage-per-node) based on the amount of data that you store. In\npractice, though, you might need those extra nodes so that your clusters can\nkeep up with incoming traffic, not only to support the amount of data that\nyou're storing.\n\nUse cases for HDD storage\n-------------------------\n\nHDD storage is suitable for use cases that meet all of the following criteria:\n\n- You expect to store at least 10 TB of data.\n- You will not use the data to back a user-facing or latency-sensitive application.\n- You don't plan to enable [2x node\n scaling](/bigtable/docs/scaling#node-scaling-factor).\n- Your workload falls into one of the following categories:\n\n - Batch workloads with scans and writes, and no more than occasional random reads of a small number of rows or point reads.\n - Data archival, where you write large amounts of data and rarely read that data.\n\nFor example, if you plan to store extensive historical data for a large number\nof remote-sensing devices and then use the data to generate daily reports, the\ncost savings for HDD storage might justify the performance tradeoff. On the\nother hand, if you plan to use the data to display a real-time dashboard, it\nprobably *would not* make sense to use HDD storage---reads would be much more\nfrequent in this case, and reads that are not scans are much slower\nwith HDD storage.\n\nSwitching between SSD and HDD storage\n-------------------------------------\n\nWhen you create a Bigtable instance, your choice of\nSSD or HDD storage for the instance is permanent. You cannot use the\nGoogle Cloud console to change the type of storage that is used for the instance.\n\nIf you want to change the storage type that a table is stored on, use the\n[backups feature](/bigtable/docs/managing-backups):\n\n1. Create or plan to use an instance that uses the storage type you want.\n2. Create a backup of the table.\n3. Restore from the backup to a new table in the other instance.\n\nWhat's next\n-----------\n\n[Create an instance with SSD or HDD storage](/bigtable/docs/creating-instance)."]]
