


约 1亿条记录, 每条1k左右,key =>value形式,用于前台查询,选择什么作为存储方案比较合适呢,要求效率比较高并且相对稳定可靠?
每天需要从文件导入一次,目前想到使用mysql分表存储,不知道有没有更好的办法。
回复内容:
对于这个小问题, 如果 key 比较小, 可以将所有 key-pos 放内存, pos 为文件中 value 的偏移, 每次访问只需要一次磁盘seek.用 protocol-buf 或 thrift 架成网络服务, 还可以加一层proxy, 按 key hash 分发到不同的服务器来减小压力.
嗯, 好像这些, beansdb 都已经做好了. 数据之间没有强关联,这种情况下用mongo+redis是比较合适的,热点数据保留在redis里,其他数据md5分散到若干台mongodb. 然后请求分散到不同的mongodb上.
扩展也方便 1.总元数据量是100G不到,加上主键索引的话,预计100G-120G
2.每天需要从文件导入一次,目前想到使用mysql分表存储,不知道有没有更好的办法 ?这个不太清楚,是当下已经有1亿条记录,还是每天累加在一起之后,可能为1亿条记录
这个非常关键,若是每天累计在一起是1亿条记录,且是按PK查询查询的话,没有必要分表
3.非常关键的一点,只有查询 还是可能也提供其他的操作,比如UPDATE,INSERT,一定要确认清楚
4.查询的话是按PK单条的方式,还是大批量的读出,关键点是否需要GROUP BY 统计,ORDER BY 分页
5.主键是否简单比如1个或2个整型字段的模式
6.采用MySQL的话,若是非常简单的查询,且按PK,可以考虑采用Handlersocket的模式,对于复杂的建议走SQL协议...
推荐handlersocket的技术文章资料:
HandlerSocket的原理等系列篇章
http://www.mysqlops.com/2011/10/19/handlersocket-principle.html
1. mongodb+redis
更酷,且对于你的场景来说,没有风险(即使丢失1天数据,也可以重新导入),成熟可靠.
mongodb存储数据(须使用主从or replication set),redis做cache.
2. mysql+memcached.
毫无疑问可以实现你的需求. 倒入之后只读的?用 java 随便写一个就可以了吧。index 放在内存,数据放在硬盘。如果访问有冗余,加个 cache 就好了。 使用Redis+Mysql吧,Mysql作磁带,Redis做前台的查询,比较合适。稳定,快速。 推荐用redis,它把k-v数据缓存在内存里面,性能很高,技术成熟稳定好,支持主从同步 http://www.thuir.org/thuirdb/
刚在微博上看到的,非常符合你的需求。
当然,不推荐使用不成熟的技术。 mark mysql用来存数据,redis用来查询,纯内存操作,速度绝对快!
缺点是硬件投入较大,1亿条数据全得存到redis服务器的内存里,redis里用不上的功能,全部不用。

Alat AI Hot

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool
Gambar buka pakaian secara percuma

Clothoff.io
Penyingkiran pakaian AI

AI Hentai Generator
Menjana ai hentai secara percuma.

Artikel Panas

Alat panas

Notepad++7.3.1
Editor kod yang mudah digunakan dan percuma

SublimeText3 versi Cina
Versi Cina, sangat mudah digunakan

Hantar Studio 13.0.1
Persekitaran pembangunan bersepadu PHP yang berkuasa

Dreamweaver CS6
Alat pembangunan web visual

SublimeText3 versi Mac
Perisian penyuntingan kod peringkat Tuhan (SublimeText3)

Topik panas



Sebab utama mengapa anda tidak boleh log masuk ke MySQL sebagai akar adalah masalah kebenaran, ralat fail konfigurasi, kata laluan tidak konsisten, masalah fail soket, atau pemintasan firewall. Penyelesaiannya termasuk: periksa sama ada parameter pengikat di dalam fail konfigurasi dikonfigurasi dengan betul. Semak sama ada kebenaran pengguna root telah diubahsuai atau dipadam dan ditetapkan semula. Sahkan bahawa kata laluan adalah tepat, termasuk kes dan aksara khas. Semak tetapan dan laluan kebenaran fail soket. Semak bahawa firewall menyekat sambungan ke pelayan MySQL.

Apabila MySQL mengubahsuai struktur jadual, kunci metadata biasanya digunakan, yang boleh menyebabkan jadual dikunci. Untuk mengurangkan kesan kunci, langkah -langkah berikut boleh diambil: 1. Simpan jadual yang tersedia dengan DDL dalam talian; 2. Melakukan pengubahsuaian kompleks dalam kelompok; 3. Beroperasi semasa tempoh kecil atau luar puncak; 4. Gunakan alat PT-OSC untuk mencapai kawalan yang lebih baik.

Penyederhanaan Integrasi Data: AmazonRDSMYSQL dan Integrasi Data Integrasi Zero ETL Redshift adalah di tengah-tengah organisasi yang didorong oleh data. Proses tradisional ETL (ekstrak, menukar, beban) adalah kompleks dan memakan masa, terutamanya apabila mengintegrasikan pangkalan data (seperti Amazonrdsmysql) dengan gudang data (seperti redshift). Walau bagaimanapun, AWS menyediakan penyelesaian integrasi ETL sifar yang telah mengubah keadaan ini sepenuhnya, menyediakan penyelesaian yang mudah, hampir-sebenar untuk penghijrahan data dari RDSMYSQL ke redshift. Artikel ini akan menyelam ke integrasi RDSMYSQL Zero ETL dengan redshift, menjelaskan bagaimana ia berfungsi dan kelebihan yang dibawa kepada jurutera dan pemaju data.

MySQL boleh mengendalikan pelbagai sambungan serentak dan menggunakan multi-threading/multi-pemprosesan untuk menetapkan persekitaran pelaksanaan bebas kepada setiap permintaan pelanggan untuk memastikan bahawa mereka tidak terganggu. Walau bagaimanapun, bilangan sambungan serentak dipengaruhi oleh sumber sistem, konfigurasi MySQL, prestasi pertanyaan, enjin penyimpanan dan persekitaran rangkaian. Pengoptimuman memerlukan pertimbangan banyak faktor seperti tahap kod (menulis SQL yang cekap), tahap konfigurasi (menyesuaikan max_connections), tahap perkakasan (meningkatkan konfigurasi pelayan).

1. Gunakan indeks yang betul untuk mempercepatkan pengambilan data dengan mengurangkan jumlah data yang diimbas memilih*frommployeesWherElast_name = 'Smith'; Jika anda melihat lajur jadual beberapa kali, buat indeks untuk lajur tersebut. Jika anda atau aplikasi anda memerlukan data dari pelbagai lajur mengikut kriteria, buat indeks komposit 2. Elakkan pilih * Hanya lajur yang diperlukan, jika anda memilih semua lajur yang tidak diingini, ini hanya akan memakan lebih banyak pelayan dan menyebabkan pelayan melambatkan pada masa yang tinggi atau kekerapan misalnya, jadual anda

Dalam pangkalan data MySQL, hubungan antara pengguna dan pangkalan data ditakrifkan oleh kebenaran dan jadual. Pengguna mempunyai nama pengguna dan kata laluan untuk mengakses pangkalan data. Kebenaran diberikan melalui perintah geran, sementara jadual dibuat oleh perintah membuat jadual. Untuk mewujudkan hubungan antara pengguna dan pangkalan data, anda perlu membuat pangkalan data, membuat pengguna, dan kemudian memberikan kebenaran.

MySQL tidak boleh berjalan secara langsung di Android, tetapi ia boleh dilaksanakan secara tidak langsung dengan menggunakan kaedah berikut: menggunakan pangkalan data ringan SQLite, yang dibina di atas sistem Android, tidak memerlukan pelayan yang berasingan, dan mempunyai penggunaan sumber kecil, yang sangat sesuai untuk aplikasi peranti mudah alih. Sambungkan jauh ke pelayan MySQL dan sambungkan ke pangkalan data MySQL pada pelayan jauh melalui rangkaian untuk membaca dan menulis data, tetapi terdapat kelemahan seperti kebergantungan rangkaian yang kuat, isu keselamatan dan kos pelayan.

MySQL mempunyai versi komuniti percuma dan versi perusahaan berbayar. Versi komuniti boleh digunakan dan diubahsuai secara percuma, tetapi sokongannya terhad dan sesuai untuk aplikasi dengan keperluan kestabilan yang rendah dan keupayaan teknikal yang kuat. Edisi Enterprise menyediakan sokongan komersil yang komprehensif untuk aplikasi yang memerlukan pangkalan data yang stabil, boleh dipercayai, berprestasi tinggi dan bersedia membayar sokongan. Faktor yang dipertimbangkan apabila memilih versi termasuk kritikal aplikasi, belanjawan, dan kemahiran teknikal. Tidak ada pilihan yang sempurna, hanya pilihan yang paling sesuai, dan anda perlu memilih dengan teliti mengikut keadaan tertentu.
