データベースhashライブラリ
昨日新しいプロジェクトがオンラインになって、データベースの最初のロジックはUIDによって型を取って分庫の分表を分けます.(psがテスト環境で使用されている単一ライブラリ単一テーブル)の結果、オンラインになった翌日、すべてのデータが1つのライブラリに存在することが分かった.
以上、解決策を提示しないことができます.
理由は簡単で、アプリケーション側にはライブラリ・テーブルの論理がありません(開発者の離職により、この部分が空白になります).
DBAはデータのバランスをチェックしていません(実はこの時のDBAはすでにデータ統計部に派遣されていて、急いでいます).
全体的には、アプリケーション側とDBAのコミュニケーションが欠けています.
個人はpythonでデータの問題を解決します.
ここで、データはprimary keyに基づいて分類される(重複キーの発生を防止する).
オンラインでは1日に数万件のデータがあります.だからすぐに解決した
SQLでも大丈夫です
仕事の簡単なまとめでしょう.
(今後、新しいオンラインアプリケーションでは、ライブラリ内のデータ量を簡単に比較して問題を発見したり、テストデータを挿入して問題があるかどうかを確認したりすることができます)
以上、解決策を提示しないことができます.
理由は簡単で、アプリケーション側にはライブラリ・テーブルの論理がありません(開発者の離職により、この部分が空白になります).
DBAはデータのバランスをチェックしていません(実はこの時のDBAはすでにデータ統計部に派遣されていて、急いでいます).
全体的には、アプリケーション側とDBAのコミュニケーションが欠けています.
個人はpythonでデータの問題を解決します.
import MySQLdb
import sys
try:
conn=MySQLdb.connect(host='127.0.0.1',user='root',passwd='xxx')
cursor=conn.cursor()
cursor.execute("select * from xxx.user_equip_diamonds")
uinfo=cursor.fetchall()
for context in uinfo:
co=int(context[5]%9)
if co in (4,5,6,7,8,9):
cursor.execute("insert into test.user_equip_diamonds select * from dragon0.user_equip_diamonds where id=%d" % (int(context[0])))
cursor.close()
conn.commit()
conn.close()
finally:
conn.close()
sys.exit(1)
ここで、データはprimary keyに基づいて分類される(重複キーの発生を防止する).
オンラインでは1日に数万件のデータがあります.だからすぐに解決した
SQLでも大丈夫です
select id from XXXX.XXXX where user_id%9 in (4,5,6,7,8,9);
temporary table id , join ,
仕事の簡単なまとめでしょう.
(今後、新しいオンラインアプリケーションでは、ライブラリ内のデータ量を簡単に比較して問題を発見したり、テストデータを挿入して問題があるかどうかを確認したりすることができます)