Мне нужна помощь от гуру базы данных.Обработка больших данных с помощью MySQL и Redis
У меня есть большая база данных с более чем 1,5 ГБ при экспорте в файл SQL в MySQL.
Проблема, с которой я столкнулась, заключается в том, что запрос на таблицы, такие как статистика, в которой хранятся миллионы данных, просто приводит к сбою сервера.
Теперь я думаю о нескольких решениях этого вопроса, и я склоняюсь к реализации Redis для больших таблиц, тогда как Redis и MySQL работают вместе. Я думаю, что я должен поддерживать MySQL, поскольку он имеет множество сложных отношений, созданных особенно при определении разрешений и списков контроля доступа. Также я не уверен, что Redis безопасен для хранения конфиденциальных данных, таких как платежи.
Это лучший способ решить проблему?
Отличительной чертой этого я слышу, что MySQL-осколки, которые я слышал, весьма эффективны для повышения производительности.
Что бы вы сделали в этом случае?
UPDATE - это то, что я от MySQLTuner:
-------- Performance Metrics -------------------------------------------------
[--] Up for: 9d 1h 9m 33s (98M q [126.517 qps], 2M conn, TX: 354B, RX: 15B)
[--] Reads/Writes: 82%/18%
[--] Total buffers: 232.0M global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 647.2M (10% of installed RAM)
[OK] Slow queries: 0% (876/98M)
[!!] Highest connection usage: 100% (152/151)
[OK] Key buffer size/total MyISAM indexes: 8.0M/294.2M
[OK] Key buffer hit rate: 100.0% (148B cached/2M reads)
[OK] Query cache efficiency: 81.0% (64M cached/79M selects)
[!!] Query cache prunes per day: 36845
[OK] Sorts requiring temporary tables: 0% (27 temp sorts/7M sorts)
[!!] Joins performed without indexes: 8358004
[!!] Temporary tables created on disk: 44% (8M on disk/18M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (400 open/266K opened)
[OK] Open file limit used: 38% (398/1K)
[OK] Table locks acquired immediately: 99% (42M immediate/42M locks)
[OK] InnoDB data size/buffer pool: 67.8M/128.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
max_connections (> 151)
wait_timeout (< 28800)
interactive_timeout (< 28800)
query_cache_size (> 64M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
thread_cache_size (start at 4)
table_cache (> 400)
1.5GB ничего для MySQL, вы уверены, что правильно настроили свой MySQL? Кажется, вы его не трогали, и вы уже думаете, что это поможет другому программному обеспечению :) –
1.5 GB ничто по современному стандарту. Любой современный MySQL-аромат должен иметь возможность обрабатывать этот том без проблем. –
Я предполагаю, что оптимизация запросов поможет. Проблема возникает, когда я делаю запрос для отчетов, которые идут через таблицу статистики с миллионами строк, а также делает несколько левых объединений по мере необходимости. Должен ли я попытаться вообще не присоединяться, поскольку он значительно замедляется? –