検索

数据库硬件选择

Jun 07, 2016 pm 03:47 PM
データベースハードウェア選ぶ

So you need to purchase a new database server, and you really don’t know where to start.. Because their maybe different recommendations for different OS’s I am going to stick with Linux with these recommendations. I want to say right off

So you need to purchase a new database server, and you really don’t know where to start..

Because their maybe different recommendations for different OS’s I am going to stick with Linux with these recommendations.  I want to say right off the bat here… choosing the right hardware should probably not be a five minute task.  I think you really need to spend time reviewing your application, it’s access patterns, the io capacity, etc.  You just can’t do this in five minutes generally.  But if your under the gun and asked me to spec something out today… here are some general guidelines.

As of  March 10th 2009 here is what I would recommend ( This are going to change every few months potentially with new versions of MySQL & new hardware:

CPU:
Currently the scalability of Innodb beyond 8 cores is limited, in fact with the current ( unpatched ) releases you may see a performance regression with more then 8 cores.  We wrote about this before.  If you have the money go with the fastest CPU’s available.  Avoid servers with lots of cores and a lower speeds.

Memory:
The more memory generally the better.  Here I would shoot for an amount of memory that will allow 100% of your hot data to be in memory.  If you do not know how much data is going to be hot, a good guess in my experience is 10-20% of the total database size , but that’s going to vary from application to application.   If you can’t figure out the total host data, more is better or a 20% rule of thumb is better then nothing.  Minimally plan for 2-4GB of memory to be allocated to the OS.  Typically I want at least 4GB of memory for the OS, and if I have a really active database I want more ( 8GB+ ).  When I say 4GB for the OS, this will also be used for the MySQL Per thread buffers/thread stack, etc.  So if you have a 24GB Database and all 24GB is hot or going to be used frequently I may put in 32GB of memory in my system and allocate 24GB to innodb and reserve the other 8GB for the OS and other items.

Disk:
Disk is going to be a toughy in 5 minutes.  You really have two concerns here, Disk capacity & IO Capacity (think io’s per second).  Disk capacity is generally pretty easy, I need XGB of disk space…  most people can estimate this no problems.   Keep in mind with RAID you will lose some raw disk capacity ( I.e. 4 160GB drives in a RAID 10 setup will deliver ~320GB of usable space ).    A 5 minute answer to IO capacity is a bit more of a challenge.    One of the descisions  yo will need to make if you can get by with internal disk or you need a SAN.  Just the other day Peter Z wrote about when to choose a SAN…  give it a read.  Assuming your making a decision in 5 mintes I am going to make an assumption that your going to look for internal disk.   Purchasing the correct SAN in my opinion requires a lot of thought.   So Let assume you want to use internal disk. First If all of your data fits into memory, it lessons your disk requirements a bit but it will not eliminate disk IO   ( your still going to read and write to disk, but your reads should be lessened ).  I strongly urge that you keep the database and OS completely separate.   So that’s 2 disks for the OS ( mirrored disks should be fine ).  For the database I typically recommend RAID10 for the data ( RAID 5 maybe OK for database with fewer writes, I.e.  data warehouses )  which means a minimum of 4 disks for your database.  So thats 6 disks to start with.  You can then scale up from there  as you need more, without more analysis your going to be guessing here.     In terms of the type of drives, SAS or SCSI in either 10K or 15K speeds are pretty standard.  I would avoid SATA drives that are

Disk Controller:
Cache on your disk controller is important and the more the better in most cases. Make sure your controller has a battery backup, otherwise its really useless.

Network Cards:

Purchase at least two network cards for your system, both full 1GBE. Typically I would bond these two nics together to give some redundancy.  Also avoid dropping your new server into a 100Mb/s network as well.

A quick note on the OS… make sure you install a 64 bit OS!

原文:http://www.bigdbahead.com/?p=158

声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
Innodb Redoログの役割を説明し、ログを元に戻します。Innodb Redoログの役割を説明し、ログを元に戻します。Apr 15, 2025 am 12:16 AM

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明出力(タイプ、キー、行、追加)で探す重要なメトリックは何ですか?説明出力(タイプ、キー、行、追加)で探す重要なメトリックは何ですか?Apr 15, 2025 am 12:15 AM

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

説明の一時的なステータスを使用し、それを回避する方法は何ですか?説明の一時的なステータスを使用し、それを回避する方法は何ですか?Apr 15, 2025 am 12:14 AM

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB

さまざまなSQLトランザクションの分離レベル(読み取り、commited、繰り返し読み取り、シリアル化可能、シリアル化可能)とmysql/innodbの意味を説明してください。さまざまなSQLトランザクションの分離レベル(読み取り、commited、繰り返し読み取り、シリアル化可能、シリアル化可能)とmysql/innodbの意味を説明してください。Apr 15, 2025 am 12:11 AM

MySQL/INNODBは、4つのトランザクション分離レベルをサポートしています。 1.ReadunCommittedは、知らないデータを読み取ることができます。 2。読み込みは汚い読み取りを回避しますが、繰り返しのない読みが発生する可能性があります。 3. RepeatablerEadはデフォルトレベルであり、汚い読み取りと非回復不可能な読みを避けますが、幻の読み取りが発生する可能性があります。 4. Serializableはすべての並行性の問題を回避しますが、同時性を低下させます。適切な分離レベルを選択するには、データの一貫性とパフォーマンス要件のバランスをとる必要があります。

MySQL対その他のデータベース:オプションの比較MySQL対その他のデータベース:オプションの比較Apr 15, 2025 am 12:08 AM

MySQLは、Webアプリケーションやコンテンツ管理システムに適しており、オープンソース、高性能、使いやすさに人気があります。 1)PostgreSQLと比較して、MySQLは簡単なクエリと高い同時読み取り操作でパフォーマンスが向上します。 2)Oracleと比較して、MySQLは、オープンソースと低コストのため、中小企業の間でより一般的です。 3)Microsoft SQL Serverと比較して、MySQLはクロスプラットフォームアプリケーションにより適しています。 4)MongoDBとは異なり、MySQLは構造化されたデータおよびトランザクション処理により適しています。

MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか?MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか?Apr 14, 2025 am 12:18 AM

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL:新規ユーザー向けのリソースとチュートリアルMySQL:新規ユーザー向けのリソースとチュートリアルApr 14, 2025 am 12:16 AM

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1)テーブル、行、列、SQLクエリなどの基本概念を理解します。 2)MySQLの定義、作業原則、および利点を学びます。 3)インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4)インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

実際のmysql:例とユースケース実際のmysql:例とユースケースApr 14, 2025 am 12:15 AM

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1)基本的な使用法:ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2)高度な使用法:eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3)パフォーマンスの最適化:インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

PhpStorm Mac バージョン

PhpStorm Mac バージョン

最新(2018.2.1)のプロフェッショナル向けPHP統合開発ツール

WebStorm Mac版

WebStorm Mac版

便利なJavaScript開発ツール

AtomエディタMac版ダウンロード

AtomエディタMac版ダウンロード

最も人気のあるオープンソースエディター

Dreamweaver Mac版

Dreamweaver Mac版

ビジュアル Web 開発ツール