En raison des limitations de MySQL, de nombreux sites adoptent l'architecture MySQL Memcached.
Certains autres sites ont abandonné MySQL et ont adopté NoSQL, comme TokyoCabinet/Tyrant et ainsi de suite.
Il est indéniable que NoSQL est beaucoup plus rapide que MySQL lors de l'exécution de certaines requêtes simples (en particulier les requêtes de clé primaire). Et la grande majorité des requêtes sur le site Web sont des requêtes simples comme celle-ci.
Mais DeNA utilise MySQL et Memcached et a créé un record de 750 000 requêtes simples par seconde sur un seul serveur ordinaire.
Peut-être que vous ne croirez pas qu'un seul MySQL peut atteindre 750 000 qps, mais c'est un fait. Parlons-en en détail ci-dessous.
SQL est-il vraiment adapté aux requêtes de clé primaire??
Les applications de la société DeNA nécessitent souvent une requête de clé primaire (PK). Par exemple, les informations utilisateur sont récupérées en fonction de l'identifiant de l'utilisateur et le contenu du journal est récupéré en fonction de l'identifiant du journal. Memcached et NoSQL conviennent très bien à ce genre de choses.
Si memcached est testé, il est très probable que 400 000 opérations get puissent être effectuées par seconde, même si memcached et le client sont situés sur des serveurs différents.
Sur un serveur doté d'une carte réseau Nehalem 3 kiloM à 8 c?urs à 2,5 GHz, libmemcached et memcached peuvent effectuer 420 000 opérations d'obtention par seconde.
Et mysql5?? Combien de requêtes PK peuvent être effectuées par seconde??
innodb?:
[matsunobu@host ~]$ mysqlslap --query="select user_name,.. from test.user where user_id=1" / --number-of-queries=10000000 --concurrency=30 --host=xxx -uroot -p
De plus, vous pouvez également utiliser des outils tels que sysbench ou super-smack.
Ouvrez une nouvelle coque et jetez-y un ?il?:
[matsunobu@host ~]$ mysqladmin extended-status -i 1 -r -uroot / | grep -e "Com_select" | Com_select | 107069 | | Com_select | 108873 | | Com_select | 108921 | | Com_select | 109511 | | Com_select | 108084 | | Com_select | 108115 |
100 000 qps représentent environ 1/4 de Memcached.
Pourquoi est-ce si lent??
Le serveur dispose de suffisamment de mémoire et toutes ces données doivent être en mémoire.
C'est aussi une opération de mémoire, pourquoi mysql est-il tellement plus lent que memcached??
les données vmstat sont les suivantes?:
[matsunobu@host ~]$ vmstat 1 r b swpd free buff cache in cs us sy id wa st 23 0 0 963004 224216 29937708 58242 163470 59 28 12 0 0 24 0 0 963312 224216 29937708 57725 164855 59 28 13 0 0 19 0 0 963232 224216 29937708 58127 164196 60 28 12 0 0 16 0 0 963260 224216 29937708 58021 165275 60 28 12 0 0 20 0 0 963308 224216 29937708 57865 165041 60 28 12 0 0
% Le processeur occupé par l'utilisateur et %le système est assez élevé.
Regardez les informations statistiques d'oprofile :
ps : Cet outil est bon, niveau noyau.
samples % app name symbol name 259130 4.5199 mysqld MYSQLparse(void*) 196841 3.4334 mysqld my_pthread_fastmutex_lock 106439 1.8566 libc-2.5.so _int_malloc 94583 1.6498 bnx2 /bnx2 84550 1.4748 ha_innodb_plugin.so.0.0.0 ut_delay 67945 1.1851 mysqld _ZL20make_join_statistics P4JOINP10TABLE_LISTP4ItemP16st_dynamic_array 63435 1.1065 mysqld JOIN::optimize() 55825 0.9737 vmlinux wakeup_stack_begin 55054 0.9603 mysqld MYSQLlex(void*, void*) 50833 0.8867 libpthread-2.5.so pthread_mutex_trylock 49602 0.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql 47518 0.8288 libc-2.5.so memcpy 46957 0.8190 vmlinux .text.elf_core_dump 46499 0.8111 libc-2.5.so malloc
MYSQLparse est en version 5.x, et YYparse en 4.x
MYSQLparse() et MYSQLlex() sont appelés lorsque mysql analyse les instructions SQL.
make_join_statistics() et JOIN::optimize() sont appelés pendant la phase d'optimisation des requêtes.
C'est précisément à cause de l'utilisation d'instructions SQL qu'il existe ces charges supplémentaires.
Les conclusions suivantes peuvent être tirées de la sortie d'oprofile?:
La couche SQL affecte sérieusement les performances des requêtes MySQL.
Par rapport à Memcached et SQL, MySQL doit effectuer un travail supplémentaire?:
* Analyse des instructions SQL Analyse des instructions SQL
* Ouverture, verrouillage des tables Ouverture et verrouillage des tables
* Faire des plans d'exécution SQL ???
* Déverrouiller, fermer des tables Déverrouiller et fermer des tables
Remarque de Hua Rong?: utilisez l'API d'instructions préparées dans mysqli pour éviter d'analyser les instructions SQL.
Mysql doit également effectuer de nombreux contr?les de concurrence. Par exemple, lors de l'envoi/réception de paquets de données réseau, fcntl() sera appelé de très nombreuses fois.
Mutex globaux?: LOCK_open LOCK_thread_count est également appelé fréquemment.
Donc, dans la sortie d'oprofile, le deuxième est my_pthread_fastmutex_lock(). Et le CPU occupé par %system est assez élevé (28%).
En fait, l'équipe de développement MySQL et certains groupes de développement périphériques comprennent l'impact d'un grand nombre de contr?les de concurrence sur les performances
Ils ont résolu certains problèmes dans MySQL 5.5. Dans le futur MySQL, %system occupera de moins en moins de CPU.
Mais que faire des 60?% de processeur occupés par %user??
Mutex contentions result in %system increase, not %user increase
Même si tous les problèmes de concurrence sont résolus, on estime qu'il sera difficile d'atteindre 300 000 qps.
Peut-être avez-vous entendu dire que les performances de l'instruction HANDLER sont également bonnes.
Mais l'instruction HANDLER nécessite une analyse des requêtes et une table d'ouverture/fermeture.
Cela ne sera pas d’une grande aide.
Dans le cas d'opérations de mémoire pleine, l'efficacité du CPU est très importante
Si seulement une petite partie des données peut entrer la mémoire, puis l'instruction SQL. La charge supplémentaire d'analyse n'est rien.
Parce que les opérations d'E/S disque prendront plus de temps.
Dans notre serveur MySQL, la mémoire est énorme et presque toutes les données peuvent être mises en mémoire.
La couche SQL devient une charge supplémentaire et consomme beaucoup de ressources CPU.
在線上的應(yīng)用中,我們要進(jìn)行大量的PK查詢。即使70-80%的查詢都是在同一張表上進(jìn)行的, mysql還是每次都要parse/open/lock/unlock/close,看起來就感覺效率低下。
We needed to execute lots of primary key lookups(i.e. SELECT x FROM t WHERE id=?) or limited range scans. Even though 70-80% of queries were simple PK lookups from the same table (difference was just values in WHERE), every time MySQL had to parse/open/lock/unlock/close, which seemed not efficient for us.
花榮注:難道說mysql中的table_open_cache不是用來減少table open的次數(shù)的么。。
NDBAPI
有沒有辦法在sql層進(jìn)行優(yōu)化呢?
http://dev.mysql.com/doc/ndbapi/en/index.html
如果你使用mysql cluster, NDBAPI會是最佳解決方案。
It’s recommended using NDBAPI for frequent access patterns, and using SQL + MySQL + NDB for ad-hoc or infrequent query patterns.
這就是我們想要的:
1 faster access API.
2 sql語句仍然要可用,以處理一些特定的或者復(fù)雜的查詢。
但是,把innodb轉(zhuǎn)化成ndb可不是一件輕松的事情。
HandlerSocket Plugin
最好的辦法是在mysql內(nèi)部實(shí)現(xiàn)一個(gè)NoSQL的網(wǎng)絡(luò)服務(wù)。daemon plugin。
它監(jiān)聽在某個(gè)端口,接受NoSQL 協(xié)議/API的數(shù)據(jù)包,使用Mysql internal storage engine API直接在innodb數(shù)據(jù)表上進(jìn)行操作,并且返回相應(yīng)的數(shù)據(jù)。
關(guān)于mysql internal storage engine API可以看這個(gè)文檔:
http://m.miracleart.cn/
這個(gè)概念首先被Cybozu Labs 的Kazuho Oku 提出,然后他寫了一個(gè)MyCached UDF,用的是memcached的協(xié)議。
http://developer.cybozu.co.jp/kazuho/2009/08/mycached-memcac.html
隨后,Akira Higuchi 寫了另外一個(gè)plugin: HandlerSocket。
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL
從圖中可以看到,客戶端既可以使用普通的mysql api來操作mysql(3306端口),
也可以使用HandlerSocket API對數(shù)據(jù)庫進(jìn)行PK查詢,以及INSERT/UPDATE/DELETE操作(9998與9999端口)。
在使用HandlerSocket操作的時(shí)候,省去了SQL parsing, Opening table, Making Query Plans, Closing table等步驟。
而且數(shù)據(jù)都是保存在原來的INNODB表中的。
在HandlerSocket操作innodb數(shù)據(jù)表的時(shí)候,顯然也需要open/close table。
但它只打開一次,然后會reuse。
由于open/close table非常耗時(shí),并且會帶來嚴(yán)重的mutex競爭,所以這種改進(jìn),極大地提升了性能。
Of course HandlerSocket closes tables when traffics become small etc so that it won’t block administrative commands (DDL) forever.
memcached主要用來緩存數(shù)據(jù)集(database records)。
因?yàn)閙emcached的get操作比mysql的PK查詢要快得多。
如果HandlerSocket獲取數(shù)據(jù)的速度比memcached還要快,那么我們就沒必要再使用memcached來緩存數(shù)據(jù)集了。做做其它緩存還是可以的。比如生成出來的HTML代碼,還有一些統(tǒng)計(jì)數(shù)據(jù)等等。
花榮注:貌似我從來沒有直接把mysql的數(shù)據(jù)集扔到memcached中。一直都是把中間結(jié)果保存到里面。難道走偏了?
使用 HandlerSocket
看下面這張user表:
CREATE TABLE user ( user_id INT UNSIGNED PRIMARY KEY, user_name VARCHAR(50), user_email VARCHAR(255), created DATETIME ) ENGINE=InnoDB;
在mysql中取出數(shù)據(jù)的方法如下:
mysql> SELECT user_name, user_email, created FROM user WHERE user_id=101; +---------------+-----------------------+---------------------+ | user_name | user_email | created | +---------------+-----------------------+---------------------+ | Yukari Takeba | yukari.takeba@dena.jp | 2010-02-03 11:22:33 | +---------------+-----------------------+---------------------+
在HandlerSocket中怎樣操作呢?
安裝HandlerSocket
詳細(xì)文檔看這里:
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL/blob/master/docs-en/installation.en.txt
大概安裝步驟如下:
1 下載
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL
2 編譯 HandlerSocket客戶端和服務(wù)器端程序:
./configure --with-mysql-source=... --with-mysql-bindir=... ; make; make install
3 安裝插件
mysql> INSTALL PLUGIN 'HandlerSocket' SONAME 'HandlerSocket.so';
安裝完畢。不需要修改mysql的源代碼。
mysql需要5.1或者以后版本。
編寫HandlerSocket 客戶端代碼
目前HandlerSocket客戶端只有C++ 和 Perl的庫。還沒有php和C的。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | #!/usr/bin/perl use strict; use warnings; use Net::HandlerSocket; #1. establishing a connection my $args = { host => 'ip_to_remote_host', port => 9998 }; my $hs = new Net::HandlerSocket($args); #2. initializing an index so that we can use in main logics. # MySQL tables will be opened here (if not opened) my $res = $hs->open_index(0, 'test', 'user', 'PRIMARY', 'user_name,user_email,created'); die $hs->get_error() if $res != 0; #3. main logic #fetching rows by id #execute_single (index id, cond, cond value, max rows, offset) $res = $hs->execute_single(0, '=', [ '101' ], 1, 0); die $hs->get_error() if $res->[0] != 0; shift(@$res); for (my $row = 0; $row < 1; ++$row) { my $user_name= $res->[$row + 0]; my $user_email= $res->[$row + 1]; my $created= $res->[$row + 2]; print "$user_name/t$user_email/t$created/n"; } #4. closing the connection $hs->close(); |
這段腳本從user表中取出來了 user_name, user_email 和created字段。
[matsunobu@host ~]$ perl sample.pl Yukari Takeba yukari.takeba@dena.jp 2010-02-03 11:22:33
對于HandlerSocket,推薦使用persistent connection。以減少數(shù)據(jù)庫連接的次數(shù)。
HandlerSocket協(xié)議 is a small-sized text based protocol。
與memcached類似,可以使用telnet來獲取數(shù)據(jù)。
[matsunobu@host ~]$ telnet 192.168.1.2 9998 Trying 192.168.1.2... Connected to xxx.dena.jp (192.168.1.2).Escape character is '^]'. P 0 test user PRIMARY user_name,user_email,created 0 1 0 = 1 101 0 3 Yukari Takeba yukari.takeba@dena.jp 2010-02-03 11:22:33
Benchmarking
測試環(huán)境:
CPU: Nehalem 8 cores, E5540 @ 2.53GHz RAM: 32GB (all data fit in the buffer pool) MySQL Version: 5.1.50 with InnoDB Plugin memcached/libmemcached version: 1.4.5(memcached), 0.44(libmemcached) Network: Broadcom NetXtreme II BCM5709 1000Base-T x 3
仍然使用上面的user表,數(shù)據(jù)大概100w行。
SQL語句為:
SELECT user_name, user_email, created FROM user WHERE userid=?
memcached和HandlerSocket的客戶端代碼都用C/C++編寫。
所有的客戶端程序都位于另外一臺機(jī)器上。通過TCP/IP與MYSQL/memcached服務(wù)器連接。
測試結(jié)果如下:
approx qps server CPU util MySQL via SQL 105,000 %us 60% %sy 28% memcached 420,000 %us 8% %sy 88% HandlerSocket 750,000 %us 45% %sy 53%
HandlerScket比傳統(tǒng)的mysql快了7.5倍,而且%us的cpu使用率為mysql的3/4。
說明SQL層還是相當(dāng)耗時(shí)的。避開SQL層之后,性能得到了明顯的提升。
HandlerSocket比memcached快了78%。而且%sy占用的cpu比memcached要少得多。
雖然memcached是一個(gè)優(yōu)秀的產(chǎn)品,但是還有很大的提升空間。
花榮注:比如七夜就改寫了memcached的部分代碼。
再來看一下HandlerSocket測試的時(shí)候oprofile的輸出:
samples % app name symbol name 984785 5.9118 bnx2 /bnx2 847486 5.0876 ha_innodb_plugin.so.0.0.0 ut_delay 545303 3.2735 ha_innodb_plugin.so.0.0.0 btr_search_guess_on_hash 317570 1.9064 ha_innodb_plugin.so.0.0.0 row_search_for_mysql 298271 1.7906 vmlinux tcp_ack 291739 1.7513 libc-2.5.so vfprintf 264704 1.5891 vmlinux .text.super_90_sync 248546 1.4921 vmlinux blk_recount_segments 244474 1.4676 libc-2.5.so _int_malloc 226738 1.3611 ha_innodb_plugin.so.0.0.0 _ZL14build_template P19row_prebuilt_structP3THDP8st_tablej 206057 1.2370 HandlerSocket.so dena::hstcpsvr_worker::run_one_ep() 183330 1.1006 ha_innodb_plugin.so.0.0.0 mutex_spin_wait 175738 1.0550 HandlerSocket.so dena::dbcontext::cmd_find_internal(dena::dbcallback_i&, dena::prep_stmt const&, ha_rkey_function, dena::cmd_exec_args const&) 169967 1.0203 ha_innodb_plugin.so.0.0.0 buf_page_get_known_nowait 165337 0.9925 libc-2.5.so memcpy 149611 0.8981 ha_innodb_plugin.so.0.0.0 row_sel_store_mysql_rec 148967 0.8943 vmlinux generic_make_request
大部分的CPU用在了網(wǎng)絡(luò)數(shù)據(jù)包的處理,取出數(shù)據(jù),等。
排在首位的bnx2是網(wǎng)卡驅(qū)動程序。
由于HandlerSocket只是一個(gè)插件,最終還會調(diào)用innodb引擎的函數(shù)去取數(shù)據(jù),
所以我們?nèi)匀豢梢允褂胢ysql命令來獲取到統(tǒng)計(jì)數(shù)據(jù)。
$ mysqladmin extended-status -uroot -i 1 -r -p| grep “InnoDB_rows_read” …| Innodb_rows_read | 750192 | | Innodb_rows_read | 751510 | | Innodb_rows_read | 757558 | | Innodb_rows_read | 747060 | | Innodb_rows_read | 748474 | | Innodb_rows_read | 759344 | | Innodb_rows_read | 753081 | | Innodb_rows_read | 754375 |
作者注:memcached和HandlerSocket的性能都會受到網(wǎng)絡(luò)IO的限制。
上面的測試是在3塊千M網(wǎng)卡的環(huán)境下進(jìn)行的。如果換成單網(wǎng)卡,HandlerSocket大概每秒處理260,000次查詢,memcached每秒處理220,000次查詢。
HandlerSocket的優(yōu)勢和特性
支持很多類型的查詢
PK肯定沒問題
unique key也可以。
普通key也可以。
limit 語句也可以。
IN 也沒問題。
INSERT/UPDATE/DELETE也沒問題。
不過,一定要用到索引才行。
不使用索引的操作不被支持。 Operations that do not use any index are not supported。
詳細(xì)說明看這里:http://m.miracleart.cn/
高并發(fā)
HandlerSocket employs epoll() and worker-thread/thread-pooling architecture,the number of MySQL internal threads is limited 。
所以放心地使用persistent connection吧。不會導(dǎo)致mysql connection太高的。
高性能
Not only HandlerSocket eliminates SQL related function calls, but also it optimizes around network/concurrency issues
HandlerSocket不僅避開了SQL層,而且優(yōu)化了網(wǎng)絡(luò)層,并解決了并發(fā)的一些問題。
更小的網(wǎng)絡(luò)數(shù)據(jù)包
與mysql協(xié)議相比,HandlerSocket協(xié)議的數(shù)據(jù)包更簡單更小。
從總體上來看,網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量會減少。
Running limited number of MySQL internal threads
不會導(dǎo)致mysql connection太高。
Grouping client requests
當(dāng)HandlerSocket接受到請求的時(shí)候,每一個(gè)處理線程都會收集盡可能多的請求,
然后一次把這些請求執(zhí)行完畢,并返回?cái)?shù)據(jù)。
看起來沒什么神奇的,但是卻可以大大地提升性能。
代價(jià)是每個(gè)請求的響應(yīng)時(shí)間略微變長。
*** Can reduce the number of fsync() calls
*** Can reduce replication delay
至于詳細(xì)情況,作者會再寫其它文章。很期待。
No duplicate cache
我們使用memcached的時(shí)候,數(shù)據(jù)會同時(shí)緩存到innodb的buffer pool與memcached中。
算是重復(fù)的cache吧。
HandlerSocket自身沒有緩存,它完全聽從InnoDB storage engine。
No data inconsistency
緩存的一大問題就是數(shù)據(jù)何時(shí)過期。
HandlerSocket沒有緩存,也就不存在這種問題。
Crash-safe
InnoDB還是相當(dāng)可靠的。
innodb-flush-log-at-trx-commit=1 加上這句就更保險(xiǎn)了。
最多會丟失死機(jī)前1秒內(nèi)的數(shù)據(jù)。
SQL can be used from mysql clients
我們?nèi)匀豢梢允褂肧QL語句進(jìn)行復(fù)雜的查詢。
確實(shí)方便很多啊。
All operational benefits from MySQL
HandlerSocket作為插件運(yùn)行于mysql內(nèi)部,所以mysql的操作,比如SQL, 熱備份,主從,Nagios監(jiān)視等等,都是支持的。
通過 show global status, show engine innodb status , show processlist 這些都可以看到HandlerSocket的狀態(tài)。
No need to modify/rebuild MySQL
無需改動mysql的源代碼或者重新編譯mysql。
線上的環(huán)境可以直接使用HandlerSocket。
Independent from storage engines
理論上講,HandlerSocket支持任何的存儲引擎,比如myisam,memory?
不過目前只在mysql5.1 5.5 InnoDB的環(huán)境下進(jìn)行過測試和應(yīng)用。
缺點(diǎn)與注意事項(xiàng)
Need to learn HandlerSocket APIs
目前只有C++和PERL庫可用。以后肯定會有php擴(kuò)展出現(xiàn)。
No security
就像其它的NoSQL數(shù)據(jù)一樣,HandlerSocket沒有任何安全方面的功能。比如權(quán)限控制之類的。
HandlerSocket的工作線程使用system權(quán)限,所以你的應(yīng)用可以存取所有的表。
當(dāng)然可以使用防火墻來限制訪問。
No benefit for HDD bound workloads
如果你的內(nèi)存不夠大,內(nèi)存要與硬盤交換數(shù)據(jù),那么HandlerSocket的優(yōu)勢就體現(xiàn)不出來了。
We use HandlerSocket on servers that almost all data fit in memory.
DeNA is using HandlerSocket in production
DeNA公司已經(jīng)在生產(chǎn)環(huán)境上使用HandlerSocket了。
The results are great!
有了HandlerSocket可以省掉很大一批memcached服務(wù)器與mysql從服務(wù)器。
而且?guī)捳加靡驳玫搅司徑狻?/span>
We’ve been very satisfied with the results。 Since HandlerSocket plugin is Open Source, feel free to try. We’d be appreciated if you give us any feedback.
?以上就是[轉(zhuǎn)]Mysql的HandlerSocket插件?的內(nèi)容,更多相關(guān)內(nèi)容請關(guān)注PHP中文網(wǎng)(m.miracleart.cn)!

Outils d'IA chauds

Undress AI Tool
Images de déshabillage gratuites

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Clothoff.io
Dissolvant de vêtements AI

Video Face Swap
échangez les visages dans n'importe quelle vidéo sans effort grace à notre outil d'échange de visage AI entièrement gratuit?!

Article chaud

Outils chauds

Bloc-notes++7.3.1
éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

1. Le premier choix pour la combinaison Laravel Mysql Vue / React dans la communauté de questions et réponses de développement PHP est le premier choix pour la combinaison Laravel Mysql Vue / React, en raison de sa maturité dans l'écosystème et de l'efficacité de développement élevée; 2. Les performances élevées nécessitent une dépendance à la cache (redis), une optimisation de la base de données, des files d'attente CDN et asynchrones; 3. La sécurité doit être effectuée avec le filtrage d'entrée, la protection CSRF, les HTTP, le cryptage de mot de passe et le contr?le d'autorisation; 4. Publicité facultative, abonnement aux membres, récompenses, commissions, paiement des connaissances et autres modèles, le noyau est de faire correspondre le ton communautaire et les besoins des utilisateurs.

Il existe trois fa?ons principales de définir des variables d'environnement dans PHP: 1. Configuration globale via Php.ini; 2. Passé via un serveur Web (tel que setenv d'Apache ou Fastcgi_param de Nginx); 3. Utilisez la fonction PUTENV () dans les scripts PHP. Parmi eux, PHP.ini convient aux configurations globales et modifiées, la configuration du serveur Web convient aux scénarios qui doivent être isolés et PUTENV () convient aux variables temporaires. Les stratégies de persistance incluent des fichiers de configuration (tels que PHP.ini ou la configuration du serveur Web), les fichiers .env sont chargés de bibliothèque Dotenv et l'injection dynamique de variables dans les processus CI / CD. Les informations sensibles à la gestion de la sécurité doivent être évitées à code dur et il est recommandé de l'utiliser.

Pour collecter les données de comportement des utilisateurs, vous devez enregistrer la navigation, la recherche, l'achat et d'autres informations dans la base de données via PHP et les nettoyer et les analyser pour explorer les préférences d'intérêt; 2. La sélection des algorithmes de recommandation doit être déterminée sur la base des caractéristiques des données: en fonction du contenu, du filtrage collaboratif, des règles ou des recommandations mitigées; 3. Le filtrage collaboratif peut être mis en ?uvre en PHP pour calculer la similitude du cosinus des utilisateurs, sélectionner K voisins les plus proches, les scores de prédiction pondérés et recommander des produits à haut score; 4. L'évaluation des performances utilise la précision, le rappel, la valeur F1 et le CTR, le taux de conversion et vérifier l'effet par le biais de tests A / B; 5. Les problèmes de démarrage à froid peuvent être atténués par des attributs de produits, des informations d'enregistrement des utilisateurs, des recommandations populaires et des évaluations d'experts; 6. Les méthodes d'optimisation des performances comprennent les résultats de recommandation en cache, le traitement asynchrone, l'informatique distribuée et l'optimisation des requêtes SQL, améliorant ainsi l'efficacité des recommandations et l'expérience utilisateur.

Lorsque vous choisissez un cadre PHP approprié, vous devez considérer de manière approfondie en fonction des besoins du projet: Laravel convient au développement rapide et fournit des moteurs de modèle éloquente et de lame, qui sont pratiques pour le fonctionnement de la base de données et le rendu de formulaire dynamique; Symfony est plus flexible et adapté aux systèmes complexes; Codeigniter est léger et adapté à des applications simples avec des exigences de performance élevées. 2. Pour assurer la précision des modèles d'IA, nous devons commencer avec une formation de données de haute qualité, une sélection raisonnable des indicateurs d'évaluation (tels que la précision, le rappel, la valeur F1), l'évaluation régulière des performances et le réglage du modèle, et assurer la qualité du code grace aux tests unitaires et aux tests d'intégration, tout en surveillant continuellement les données d'entrée pour empêcher la dérive des données. 3. De nombreuses mesures sont nécessaires pour protéger la confidentialité des utilisateurs: crypter et stocker des données sensibles (comme AES

PHP joue le r?le du connecteur et du Brain Center dans le service client intelligent, responsable de la connexion des entrées frontales, du stockage de la base de données et des services d'IA externes; 2. Lors de la mise en ?uvre, il est nécessaire de créer une architecture multicouche: le front-end re?oit des messages utilisateur, les demandes de prétraitements et de routes de PHP, correspondent d'abord à la base de connaissances locale et manque, appelez des services AI externes tels que Openai ou DialogFlow pour obtenir une réponse intelligente; 3. La gestion de session est écrite à MySQL et à d'autres bases de données par PHP pour assurer la continuité du contexte; 4. Les services d'IA intégrés doivent utiliser Guzzle pour envoyer des demandes HTTP, stocker en toute sécurité les apikeys et faire un bon travail de gestion des erreurs et d'analyse de réponse; 5. La conception de la base de données doit inclure des sessions, des messages, des bases de connaissances et des tables d'utilisateurs, de créer raisonnablement des index, d'assurer la sécurité et les performances et de prendre en charge la mémoire du robot

Pour permettre aux conteneurs PHP de prendre en charge la construction automatique, le noyau réside dans la configuration du processus d'intégration continue (CI). 1. Utilisez Dockerfile pour définir l'environnement PHP, y compris l'image de base, l'installation d'extension, la gestion de la dépendance et les paramètres d'autorisation; 2. Configurez des outils CI / CD tels que GitLabci et définissez les étapes de construction, de test et de déploiement via le fichier .gitlab-ci.yml pour réaliser une construction, un test et un déploiement automatique; 3. Intégrer des cadres de test tels que PHPUnit pour s'assurer que les tests sont automatiquement exécutés après les modifications du code; 4. Utiliser des stratégies de déploiement automatisées telles que Kubernetes pour définir la configuration de déploiement via le fichier de déploiement.yaml; 5. Optimiser Dockerfile et adopter une construction en plusieurs étapes

1. PHP entreprend principalement la collecte de données, la communication API, le traitement des règles d'entreprise, l'optimisation du cache et l'affichage de recommandation dans le système de recommandation de contenu d'IA, plut?t que d'effectuer directement une formation de modèle complexe; 2. Le système recueille le comportement des utilisateurs et les données de contenu via PHP, appelle les services d'IA back-end (tels que les modèles Python) pour obtenir des résultats de recommandation et utilise Redis Cache pour améliorer les performances; 3. Les algorithmes de recommandation de base tels que le filtrage collaboratif ou la similitude de contenu peuvent implémenter une logique légère en PHP, mais l'informatique à grande échelle dépend toujours des services d'IA professionnels; 4. L'optimisation doit prêter attention au démarrage en temps réel, au démarrage à froid, à la diversité et à la boucle fermée, et les défis comprennent des performances de concurrence élevées, la stabilité de la mise à jour du modèle, la conformité des données et l'interprétabilité des recommandations. PHP doit travailler ensemble pour créer des informations stables, une base de données et un frontal.

L'idée principale de PHP combinant l'IA pour l'analyse du contenu vidéo est de permettre à PHP de servir de "colle" backend, de télécharger d'abord la vidéo sur le stockage du cloud, puis d'appeler les services d'IA (tels que Google CloudVideoai, etc.) pour une analyse asynchrone; 2. PHP analyse les résultats JSON, extraire les personnes, les objets, les scènes, la voix et autres informations pour générer des balises intelligentes et les stocker dans la base de données; 3. L'avantage est d'utiliser l'écosystème Web mature de PHP pour intégrer rapidement les capacités d'IA, qui convient aux projets avec les systèmes PHP existants pour mettre en ?uvre efficacement; 4. Les défis courants incluent un traitement de fichiers important (directement transmis au stockage cloud avec des URL pré-signées), des taches asynchrones (introduction des files d'attente de messages), un contr?le des co?ts (analyse à la demande, une surveillance du budget) et une optimisation des résultats (standardisation de l'étiquette); 5. Les étiquettes intelligentes améliorent considérablement le visuel
