PHP가 풀뿌리 언어로 간주되는 이유는 무엇입니까?

PHPer는 풀뿌리인가요?

PHP가 탄생한 이래로 PHP는 웹 애플리케이션의 대다수 프로그래머에게 서비스를 제공하기 시작했습니다. 동시에 웹 개발에 특화된 스크립팅 언어로서 PHP는 항상 단순성과 오픈 소스라는 이념을 고수해 왔으며, 이는 PHP가 웹 2.0의 출현과 발전을 빠르고 힘차게 발전시킬 수 있게 해주었습니다. 그러나 오랫동안 PHPer(PHP 프로그래머)는 풀뿌리 수준의 프로그래머, 기술적 내용이 거의 없고 수준이 낮은 프로그래머로 간주되었습니다. 특히 국내에서는 더욱 그렇습니다.

기술감독님이 그런 말씀을 하신 기억이 나네요. 그는 프로그래머에게 PHP 개발 작업을 할당했습니다. 실제로 프로그래머는 "나는 Java 학생입니다. 나에게 PHP 작성을 요청하면 나를 무시하는 것이 아닙니까?"라고 말했습니다. 이 사건은 나에게 깊은 인상을 남겼고 큰 감동을 주었다. 이것이 대부분의 프로그래머의 견해를 대변하지는 않지만 그렇게 생각하는 사람들이 많을 것입니다. 지금 대규모 정부 프로젝트라면 PHP는 당연히 고려 대상에 포함되지 않을 것이라는 말도 있다.

그렇다면 왜 PHPer가 풀뿌리 수준으로 간주되는 걸까요? 매우 간단하고 누구나 배울 수 있어서 어렵지 않기 때문일까요? 나도 그렇게 생각하곤 했어요. PHP를 시작하는 것은 빠르고 파일 처리, 데이터 처리, 원격 연결, 네트워크 프로그래밍에 매우 편리합니다. 또한 PHP를 배우는 데 드는 비용이 매우 낮아 사용하기 쉽다고 합니다. 이 아이디어는 일반적이며 대부분의 PHP 사용자도 그렇게 생각합니다.

이렇게 말하면 다들 내가 왜 이런 말을 쓰는지 생각하실 것 같아요. 1년 넘게 PHP 홍보 작업을 하면서 PHP를 사용하는 많은 기업의 전반적인 상황을 이해할 수 있었기 때문입니다. 이러한 과정에서 나는 천천히 근본 원인을 깨닫게 되었다. 여기서 말하는 근본적인 이유는 개인적인 의견이지만 이것이 사실이라고 생각합니다.

그렇다면 PHPer가 풀뿌리 수준으로 간주되는 이유는 PHPer가 수행하는 대부분의 작업(코드를 통해 구현됨)이 프레젠테이션 계층 작업이기 때문입니다. 물론 MVC 구조로 작성된 특정 프레임워크의 기능에 대해 이야기하는 PHP도 있을 것입니다. 그러나 이는 여전히 프레젠테이션 레이어입니다. 따라서 프리젠테이션 계층만 다루는 프로그래머는 풀뿌리라고 간주됩니다. 실제로 이것은 사실입니다. 왜냐하면 이 경우 PHP가 대규모 애플리케이션을 구축하는 것이 정말 어렵기 때문입니다.

그게 이유야, 아니. PHPer가 항상 프레젠테이션 계층을 담당하는 이유는 무엇입니까? 대답은 우리가 일반적으로 기본 데이터 처리를 건드리지 않는다는 것입니다(웹 애플리케이션은 데이터 저장 및 검색입니다). 좋습니다. 이 시점에서 일부 사람들은 '이것이 데이터베이스가 아닌가?'라고 생각했을 것입니다. 예, 데이터베이스입니다. PHPer를 풀뿌리 수준으로 유지하는 주범은 데이터베이스입니다. 왜?

PHPer는 MySQL에 너무 많이 의존합니다

현재 널리 사용되는 웹 아키텍처에서는 프런트 엔드가 로드 밸런싱 시스템이고 중간이 웹 서버, 후면이 데이터베이스 서버이기 때문입니다. 따라서 대부분의 PHPer는 웹 서버 수준에서 작동합니다. 데이터베이스가 우리를 위해 데이터를 매우 잘 정리했기 때문입니다. 따라서 PHP에는 알고리즘이 많지 않으며 사람들은 성능에 영향을 미칠 것이라는 점은 말할 것도 없고 무의식적으로 알고리즘이 필요하지 않다고 느낍니다.

이 경우 PHPer는 데이터베이스 사용자가 되어 항상 데이터베이스를 운영하고 있습니다. 프로그램을 하기보다는 가장 간단한 PHP 스크립트 중 하나는 데이터베이스에 연결하고 데이터를 가져온 다음 명령을 사용하여 이를 브라우저에 출력하는 것입니다. 전체 프로세스에는 10줄 이하의 코드가 필요합니다. 너무 단순한 것 같은 느낌이 듭니다. 기술적인 내용은 없습니다. 왜냐면, 데이터 처리 부분이 데이터베이스에 의해 완료되었기 때문입니다. 특히 MySQL을 사용합니다. MySQL은 무료이므로 대부분의 프로그래머가 자유롭게 사용할 수 있습니다. 게다가 MySQL은 충분히 빠르기 때문에 PHP 애플리케이션을 만드는 것이 매우 간단합니다. 이것은 당신에게 총을 주는 것과 같으며 당신은 무술을 배울 필요가 없다고 느낍니다. 물론 총이 무술만큼 좋지 않다는 말은 아니다. 오히려 총기의 출현으로 아이들은 쉽고 편리하게 사람을 죽일 수 있게 됐다.

왜 데이터베이스인지 자세히 이야기해보자. 여기에 예를 들어 보겠습니다. 저는 베이징에 있는 아주 유명한 웹사이트에 갔었습니다. 그 당시 비교적 선배인 PHP 프로그래머가 시스템 아키텍처에 대해 이야기하고 있었습니다. 프로그래머가 모든 사람에게 데이터 구조에 대한 알고리즘 질문을 했을 때 청중 중 누구도 (나를 포함하여) 대답할 수 없었던 것을 기억합니다. 그런 다음 프로그래머는 모든 사람에게 매우 기본적인 데이터 구조를 알려주기 시작했습니다. 대학에서 배웠던 자료구조 수업을 바로 떠올려보겠습니다. 이러한 기본적인 데이터 정렬, 검색 및 전송 문제는 다른 고급 언어(예: C)에서 매우 일반적입니다. 하지만 PHP에서는 그렇지 않습니다. PHPchina.com 포럼에는 PHP 데이터 구조 및 알고리즘이라는 섹션도 있습니다. 이 섹션에도 게시물이 거의 없습니다.

그러고 보니 알겠어요? 대부분의 PHPer는 프리젠테이션 계층의 작업만 처리하며 MySQL의 편리한 사용으로 PHPer는 데이터 구조 및 알고리즘을 건드리지 않고 대부분의 개발 작업을 완료할 수 있으므로 위의 내용은 단 한 사람만 갖고 있으며 PHP 프로그래머는 문제에 답할 수 없습니다. 데이터 구조가 발생하고 C와 같은 언어로 전환되면 상황이 매우 다를 수 있습니다. PHP를 풀뿌리처럼 보이게 만드는 것은 PHPer의 풀뿌리입니다.

잘 생각해보면 인터넷에서 가장 많이 논의되는 이슈가 두 가지 있다. 하나는 PHP 클래스 사용(처리 절차의 캡슐화)이고, 다른 하나는 개발 프레임워크 문제입니다. 그러나 주의 깊게 분석해 보면 PHP에는 소위 비교적 복잡한 개념이라 불리는 데이터 처리가 없다는 것을 알 수 있습니다. 왜, 데이터베이스가 있습니다. Adodb 또는 PHP5 PDO를 사용하여 수행할 수 있습니다. 정말 끝났나요? 아니요, 데이터베이스에 연결하는 것일 뿐 데이터 처리는 없습니다. 그래서 PHPer는 테이블에 가져올 것이 아무것도 없는 것 같습니다.

특정 코드 문제, 무단계 분류에 대해 이야기해 보겠습니다. 이 개념은 다들 잘 알고 계시리라 생각합니다. 나는 그것이 두 가지 방법으로 이루어지는 것을 보았습니다. 첫 번째는 현재 상대적으로 인기가 있는 정통 PHPer 처리 방법입니다. 데이터베이스를 사용하여 처리하십시오. 그리고 필드가 거의 없습니다. 상위 클래스의 필드를 추가하고 판단하면 됩니다. 그리고 이 방법은 매우 실용적이다. 효율성도 높다. 그러나 이는 데이터 처리의 범위가 아니라 데이터베이스 검색의 범위입니다.

두 번째는 C 프로그래머가 PHP를 사용하여 작성한 것입니다. 데이터베이스에서 분류 정보를 모두 꺼낸 후 데이터 구조 알고리즘을 사용하여 정리하고 배포한 후 출력했습니다.

여기서는 이 두 가지 방법의 효율성을 비교하지 않겠습니다. 모든 사람이 각자의 생각을 가지고 있다고 생각합니다. 그러나 나는 이 두 접근 방식의 본질적인 차이점이라는 문제를 명확히 하고 싶습니다. PHPer는 처리를 위해 습관적으로 데이터베이스를 사용하는데, 매우 영리한 처리 방법을 가지고 있으며 매우 효율적입니다. 이 방법은 데이터베이스 쿼리입니다. 두 번째 방법은 좀 더 독특합니다. 그는 데이터베이스는 데이터가 저장되는 장소이며 구체적인 논리적 처리는 자신의 논리에 따라 달라진다고 믿습니다.

따라서 결론은 두 번째 방법의 사용자가 데이터의 논리를 직접 정리했기 때문에 더 강하게 느껴진다는 것입니다. 그리고 내 생각에 PHPer의 접근 방식은 데이터베이스 쿼리에 지나지 않습니다. 그래서 그는 PHPer가 풀뿌리이고 데이터베이스를 운영하고 페이지를 정렬하는 방법만 알고 있다고 생각합니다(똑똑한 종류).

데이터베이스를 원래 작업으로 되돌리세요

이쯤 되면 다들 평소 PHP 개발 경험을 많이 떠올리셨을 텐데요, 실제로 다들 데이터베이스를 운영하고 있다는 걸 아셨나요? .

그럼 이 문제에 대해 토론해 보겠습니다. 데이터베이스가 나쁜가요? 데이터베이스를 사용하여 데이터를 처리하는 데 문제가 없는 이유는 무엇입니까? 내가 말하는 것은 데이터베이스에 문제가 있고 매우 문제가 있다는 것입니다. 물론, 여기서 데이터베이스를 사용할 수 없다고 말하는 것도 아니고, 데이터베이스의 성능을 얕보는 것도 아닙니다. 오히려 우리는 데이터베이스가 수행하는 역할을 완전히 인식하지 못합니다.

한 번은 한 웹사이트의 기술 책임자가 웹사이트가 왜 이렇게 느린지, 어떻게 해야 하는지 물었습니다. 그 때 제가 다니던 MSN의 Zend 본사 엔지니어가 우연히 온라인 상태여서 PHP가 반응이 느리면 어떻게 해야 하는지 물었습니다. 당시 그는 데이터베이스 문제라고 직접 말했다. 데이터베이스가 최적화되지 않고 제대로 설계되지 않았기 때문일 것입니다. 그래서 기술이사님의 데이터베이스 설계에 저희가 관여할 수 없었기 때문에 명확한 답변을 드리지 못했습니다. 그래서 저는 몇 가지 일반적인 데이터베이스 최적화 제안을 했습니다. 이런 일이 반복적으로 발생했는데 왜 Zend 본사 엔지니어들이 매번 데이터베이스 문제라고 말했는지 궁금해졌습니다. PHP 수준에서는 이 문제를 해결할 수 없는 걸까요? 대답은 '아니요'입니다. 현재 PHP는 매우 빠르게 실행되기 때문에 Zend의 성능 분석을 통해 사용자의 클릭률도 확인할 수 있습니다. PHP의 실행 시간은 10% 미만입니다. 그렇다면 PHP는 무엇을 하고 있을까요? 기다리고 있습니다. 데이터베이스 쿼리 결과를 기다리는 중입니다. 이러한 측면은 현재 PHP 제품, 즉 캐싱 및 웹 페이지 정적화에서 크게 개선되었습니다.

캐싱은 누구에게나 생소할 수 있지만 이제 웹페이지 정적화는 PHP 제품 사용자에게도 매우 명확해졌습니다. 빠르고, 검색하기 쉽습니다. 이점은 자명합니다. 농담으로 말하자면, 웹사이트 홈페이지에 정적인 웹페이지를 구현하려면 하드 드라이브의 용량만 충분하면 됩니다. J 캐싱의 경우 더 복잡하며 대부분의 PHP 사용자에게는 골치 아픈 문제이기도 합니다. 어떤 사람들은 이를 구현하기 위해 C를 사용하기도 합니다. Caching에서는 데이터 유효기간 확인, 검색, 추출, 업데이트 등의 처리가 더 어렵기 때문입니다. 물론 일부 사람들은 캐싱 문제를 처리하기 위해 데이터베이스를 사용할 것입니다.

따라서 방문수가 급증하게 되면 PHP 구조의 웹사이트에서 발생하는 많은 문제는 데이터베이스로 인해 발생하게 됩니다. 데이터베이스 동기화 문제는 큰 문제가 아닙니다. 핵심은 데이터베이스의 응답 속도가 기하급수적으로 감소한다는 것입니다. 나는 10월 23일 LAMP 컨퍼런스에서 MySQL 부사장에게 이런 질문을 했습니다. 그 당시에는 (제가 예상했던 대로) 완벽한 대답을 하지 못했습니다. 왜냐하면 요정 데이터베이스가 아닌 이상 데이터베이스에는 항상 병목 현상이 있기 때문입니다. 하하

여기에는 여담이 있습니다. LAMP 컨퍼런스 Yahoo의 기술 임원과 대화를 나누면서 Yahoo가 MySQL이나 Oracle을 선택할 때 무엇을 고려하는지 물었습니다. 그의 대답은 나를 놀라게 했습니다. 그는 MySQL의 성능이 우리의 요구 사항을 충족하기 때문에 대부분의 경우 MySQL을 사용할 것이라고 말했습니다. 그런데 언제 오라클을 선택하게 될까요? 그때가 바로 유료 사용자의 데이터를 저장해야 하는 시점입니다. 왜 Oracle이 MySQL보다 더 안정적인지 물었습니다. 이에 대해 그는 특별히 고려한 바가 없다고 말했다. 핵심은 오라클을 사용하면 문제가 발생했을 때 담당자를 찾을 수 있고, 오라클이 사고 처리를 책임진다는 것입니다. 그런데 MySQL을 사용하면 누구에게 가야 할까요? , 데이터베이스에 대한 우리의 견해는 다음과 같아야 합니다. 이를 수정하려면 데이터베이스가 전능하지 않다는 의미입니다. 능력이 있다면 자신만의 데이터베이스를 개발하세요. 구글이 그런 회사라고 들었습니다.

그렇다면 데이터베이스에 대해 어떻게 생각하시나요? 개인적인 이해로는 데이터베이스는 단지 개발 비용을 줄이기 위한 수단일 뿐이라는 것입니다. 데이터베이스를 사용한 후에는 데이터 저장, 특히 정렬 및 검색을 고려할 필요가 없기 때문입니다. 그러나 이것이 어떤 문제를 야기하는가? 비즈니스가 확장되면 데이터베이스에 병목 현상이 발생합니다. 이때 문제는 매우 어려울 것입니다. 이것이 기본 데이터 처리이기 때문입니다. 한 번의 움직임이 몸 전체에 영향을 미칩니다.

그래서 데이터베이스는 데이터 백업 기계라는 점이 맞는 것 같아요. 이해하려면 데이터 저장의 유효성만 확인하면 됩니다. 이는 원래 데이터베이스의 핵심 기능이지만 데이터베이스의 편리한 정렬 및 기타 기능으로 인해 모든 사람이 너무 많은 처리를 데이터베이스에 맡겨야 합니다. 사용자가 PHP를 클릭하면 많은 작업이 데이터베이스로 전달되고 그 결과가 정렬되어 사용자에게 제공됩니다. 이는 데이터베이스에 불공평합니다. 그래서 모두가 데이터베이스 성능에 대해 불평하기 시작했습니다.

이 관점에 대해 또 다른 예를 들어보겠습니다. 제가 한 대형 인터넷 회사를 방문했을 때(기본적으로 중국에서 인터넷에 접속해 본 사람이라면 누구나 알고 있는 사실입니다.) 그 회사는 PHP를 거의 사용하지 않는다는 것을 알게 되었습니다. 기업에서는 데이터베이스를 사용합니다. 그들은 데이터베이스 외부에 두 번째 데이터베이스가 있다고 자랑스럽게 소개했습니다(여기에서는 이를 두 번째 데이터베이스라고 명명했습니다). 왜 제2의 데이터베이스라고 불리는 걸까요? 알고 보니 캐싱 시스템이었습니다. 그렇다면 개발 엔지니어는 어떻게 이 캐시 시스템에서 데이터를 얻습니까? 기술 책임자는 캐싱 시스템에 SQL 쿼리 문이 있다고 자랑스럽게 말했습니다. 당시엔 놀랐지만, 나한테는 이게 꼭 필요하다는 생각이 들었다. 캐시 시스템이 특정 수준에 도달하면 캐시에서 데이터를 얻는 것이 매우 복잡해지기 때문에 간단히 SQL 쿼리 문을 작성하고 캐시 시스템이 데이터를 분석, 처리 및 반환하도록 하세요. 그리고 그들은 그 자리에서 PHP를 사용하더라도 PHP가 캐시 시스템에서 데이터를 읽어오도록 요청한다고 말했습니다.

따라서 이 문제를 처리할 수 있다면 데이터를 데이터베이스에 저장하세요. 그러면 데이터베이스는 백업 역할만 할 것입니다. 그런 다음 자체 중간 계층을 사용하여 분석 데이터를 처리하면 90% 이상의 사용자가 데이터베이스에 액세스하지 않게 됩니다. 어떤 사람들은 이것이 연결 풀과 비슷한 것이 아닌가? 네, 데이터베이스의 병목 현상을 해결할 수 없기 때문에 웹 서버와 데이터베이스 사이에 중간 계층을 추가하여 버퍼링을 수행할 수만 있습니다.

아마 다들 쯧쯧, 우린 이미 알고 있었을 텐데. 글쎄요, 제가 여기서 말하고 싶은 것은 그것이 촉발한 두 가지 생각입니다:

첫째, 일부 언어에는 이미 연결 풀 기술이 있으며 프로그래머는 연결 풀을 사용하여 대규모 애플리케이션을 쉽게 구축할 수 있습니다. 그렇다면 PHPer가 데이터베이스만 사용할 것이라고 생각한다면 연결 풀만 사용할 것이라고 말할 수 있습니까? 연결 풀링과 데이터베이스의 개념적 차이점은 무엇입니까?

둘째, PHPer가 자체 캐싱 시스템을 구축하기 시작했을 때 PHPer가 데이터베이스만 사용하는 수준을 돌파했습니까? 왜냐하면 그는 데이터 로직 처리에 관여하고 있기 때문입니다. 그럼 그 사람은 아직도 풀뿌리 사람인가요?

마지막으로 독립적으로 생각할 줄 아는 PHPer는 모든 것을 데이터베이스에 맡기는 풀뿌리 사람들이 아닙니다.