UTF8 vs ASCII o formato binario personalizzato: ottimizzazione ad alte prestazioni su tavoli molto grandi

Question

Il riassunto della mia domanda è se ci sono vantaggi, anche se minimi, per usare ASCII o anche un formato più piccolo progettato ma creato specificamente per la situazione, anziché UTF-8 per le stringhe.

È possibile utilizzare WebServer che accede ai dati tradurre una stringa ASCII in un formato più compatto.

Su questa domanda, solo 1-3 tabelle sul database gestiscono una quantità enorme di dati, quindi qualsiasi byte può fare la differenza se potrebbe adattarsi alla memoria anziché alla memoria di accesso. Le informazioni saranno accessibili tramite un servizio Resfull

Leggi vs scrive:

Il progetto ha bisogno di molto più di lettura di quanto le scritture. Ma la scrittura ha una peculiarità: ogni 10 secondi un importo tra 40-300 nuove righe viene inserito nella tabella principale. Questi potrebbero essere scritti in parallelo, poiché non dipendono l'uno dell'altro.

Memoria vs Uso del disco:

Recenti righe inserite, che verranno utilizzate immediatamente, verranno inserite anche su una cache per l'uso del servizio Web, quindi non è necessario leggerle di nuovo. Ma per la ricerca su vecchi record, il database avrà bisogno e dovrebbe essere veloce.

Questo è il motivo per cui suppongo che usare meno byte per archiviare alcuni campi farà la differenza: anche per una maggiore quantità di dati, sarà più facile per adattarsi alla memoria.

Se non riesco a montare i dati sulla memoria e il database non può astrarre una certa velocità, oppure dovrò forzare le scansioni della tabella/partizione lenta ogni 10 secondi per un solo utente, oppure sarò costretto a fare singolo selezionare e memorizzare nella cache su WebServer , ma questo concetto di pausa di "apolidi" dal concetto di riposo.

Personaggi che devono essere supportati

0-9, AZ, "-", "_". Forse avrà bisogno di "AZ". Solo 38 o 64 caratters, e mai più di questo.

Per ora, la maggior parte delle colonne lo sono

CHAR(3), CHAR(6), VARCHAR(8), VARCHAR(10). 

Esempi:

• ABC, XYZ
• Ab-efg, xy-xpt
• ABC123457
• E47F6C, 34210A, E48D37 (stringhe esadecimali, forse esistono un formato specifico per questo?)

Tecnologie utilizzate

Il database sarà Mariadb. Forse parte dei dati grezzi sarà su alcuni NoSQL Banca dati. La lingua di WebService non fa davvero la differenza qui, ma sarà PHP 5.4 con Framework PhalCon PHP.

È stato possibile utilizzare diversi tipi di cache, dalla cache di vernice a APC/mencached fino alla cache all'interno del database.

La mia ipotesi iniziale:

Un campo con VARCHAR(10) ha bisogno di 80 bit. Se utilizzo una tabella personalizzata per utilizzare solo 64 o meno invece 255 caratteri, salvo circa 4 volte, quindi invece di 80 bit useranno solo 20 bit.