Roze

Izklausās nenopietni, proti, neesi ne lasījis viņu noteikumus + esi pat tos pārkāpis .. Šeit daži izvilkumi no TOS (Terms of service): - By using this site, you signify your agreement to these terms of use. If you do not agree to these terms of use, please do not use the site. - SSDapp.com is provided on an "as is," "as available" basis without warranties of any kind - Backup and Monitoring. User is solely responsible for creating backups of any files associated with the Site and for monitoring the Site. - User shall not include content, or internet links to content on the Site that contain, promote or involve any of the following: any infringement of copyright, trademark, patent, trade secret or other intellectual property right; hate propaganda; racist, threatening, or otherwise abusive content; the promotion or incitement of, or instruction for, the commission of illegal activities; mail fraud, multi-level marketing (pyramid) schemes or any other fraudulent activities; content promoted through the sending of unsolicited e-mail (also known as spamming); utt .. tā kā sašutums par "drīkst" vai "nedrīkst" ir savdabīgs.

WP postu gan var redzēt atkal šādi - nu, piemēram, paņemam to pašu ventbunkeru -> WP 3.4.2 -> https://wpvulndb.com/wordpresses/342 kas ir pietam public disclosed saraksts (un Certam atkal sanāk ko sapačkāt atskaitēs) :/ Bizness, protams, ir .. var likt atjauninājumus (kas ir priekšrocība šādiem centralizētiem servisiem) :)

Šis tomēr ir forums ar tehnoloģisku pieskaņu, līdz ar to nedaudz paanalizēt (protams, neņemot vērā plikus "tas ir sūds" vērtējumus) kas un kā notiek, manuprāt, ir gana normāli. Ir gana daudz "tooļu" kas ir burtiski "caur pakaļu". Nu, piemēram, samērā nesen nācās paskatīties vienu HP SmartArray menedžmenta gui toooooli, kas patiesībā ir apdalīts linux distro+apache+php-cgi+exec(cli) nu jopcik %(*&^%%$& .. Otra tendence ir, ka šitie "plug and play" pakalpojumi/risinājumi reizēm rada galvassāpes, proti, ja jasaskaras ar kolēģi, kas teiksim nekā savādāk nemāk pieslēgties pie datubāzes kā novelkot kaut kādu laravela moduli ar composeru, bet . mysql(i)_connect nezina .. Tas tā pārdomām.

Kas parasti ir 1 rewraits uz index.php un kādi 2-3 deny kaut kādām config/plugin direktorijām ... :E

Tāds savdabīgs serviss. - tu viņiem iedod 'root' no kaut kādas sava servera/instances (ar nosacījumu, ka iepriekš esi tur uzstādijis Ubuntu) - viņi tad tur attālināti izpildās un nezkapēc uzliek nginx -> apache -> php-fpm ( https://serverpilot.io/community/articles/how-serverpilot-configures-your-lamp-stack.html) .. .. un tad var izlasīt "Unlike Apache, Nginx can handle handle tens of thousands of simultaneous client connections. As Nginx waits until it has completely received the request before proxying the request through to Apache, your server is safe from Slowloris attacks. For your SSL-enabled apps, Nginx also provides extremely efficient SSL handling and HTTP/2 support. " .. Es vēl varētu saprast kāpēc vienkārši shared WP hostinga vietā varētu izvēlēties šādu servisu/pakalpojumu/produktu, bet kāda mārrutka pēc ir jāliek apachi vispār? Statiski faili ir nginx / ssl offloadings ir nginx / dinamisku php handlē php-fpm kas ir atsevišķš process .. so ko dara indiānis? p.s. par to SSL offloadingu nāk prātā Fastly prezentācija Futurestackā: https://www.youtube.com/watch?v=zrSvoQz1GOs&t=1485

Bruto. Oficiāli jau parasti nefigurē tādi "uz rokas" jebšu neto skaitļi, jo tad situācija (brīžiem/bieži) būtu traģikomiska - nu, piemēram, ~10% algas pielikums 20 EUR apmērā, kas patiesībā rezultējas kaut kaut kādos ~5 EUR par ko var 1x aiziet uz veikalu pienapaku ar maizesbatonu nopirkt, bet tā lepni var teikt un statistikas rādītājos iebakstīt, ka 10% algas pieaugums - ekonomiskā izaugsme vai zinies ..

Tā vispārīgi pieliekot (izpildot mysql konsolē) kverijam EXPLAIN ( https://dev.mysql.com/doc/refman/5.6/en/explain.html) : EXPLAIN select loc_from.place AS place_from, loc_to.place AS place_to, loc_from.seo_slug AS se ... .. tad mysql parādīs kur un kādus indeksus izmanto utt..

Kāpēc? Jebšu kādu caurumu? Ja tik ļoti patīk JSON formāts neredzu iemeslu kāpēc lai nemēģinātu.. Kādi performances rādītāji būs droši vien atkarīgs no konkrēta risinājuma/prasībām/dzelžiem utt .. t.i. droši vien nekas maģisks nenotiks :) Katrai rdbms ir daži savdabīgi risinājumi (tāpat piemēram MySQL ir Memcached protokols/interfeiss: http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html vai MariaDB piem ir dynamic columns https://mariadb.com/kb/en/mariadb/dynamic-columns/ kurām ar ir JSON "izskats" utt ... Izvirst var līdz nelabumam, piemēram, Handlersocket https://mariadb.com/kb/en/mariadb/handlersocket/ Spider storage engine http://mariadb.com/kb/en/mariadb/spider-storage-engine-core-concepts/ .. un ir NoSQLs uz MySQL bāzes. Mēs gan neizmantojam konkrēti šo datu tipu bet storējam blobus MySQLā - priekšrocības ir: - zināms/pierasts interfeiss - datu kompresija - replikācija (attiecīgi vienkārši backupi) utt Šeit ir vēl viens Mongodb (no situācijas) mīnuss - ja nekas būtiski nav mainījies tad MongoDB ir apmēram tā, ka principā viņs darbojas pēc Copy-on-write principa, proti lai arī katram dokumentam ir zināms ekstra space/paddings (kādreiz tas kolekcijai tika rēķināts dinamiski kā koeficients tagad šķiet noklusēti ir power-of-2 ja specifiski neizslēdz ( http://docs.mongodb.org/manual/core/storage/#power-of-2-allocation) ) tad brīdī kad dokumenta izmaiņas pārsniedz šo ekstra brīvo vietu viss dokuments/objekts tiek ierakstīts pa jaunu (ar lielāku padingu). Attiecīgi risinājumos kur notiek bieža dokumentu maiņa vai objekti ir vienmēr augoši (nu piemēram lietotājam masīvā krājās klāt kaut kādi viņa posti utt) kādā brīdī var sanākt daudz izniekotas diskvietas defragmentācijas dēļ (MongoDB automātiski pats neko necompactē http://docs.mongodb.org/manual/reference/command/compact/ kas nav online operācija - attiecīgi jāizpilda replica setā uz sekundārajiem "biedriem" pēc tam mainot masteru. Šobrīd manuprāt gan ir labāk bet 2.x versijā pie tam bija nepieciešams vismaz tikpat daudz diskvietas - proti ja DB aizņēma 500Gb tad tev vajadzēja vēl 500Gb brīvus jo tika taisīta pilna db kopija. Protams arī InnoDB ir defragmentācija, bet ne tik lielā mērogā .. tagad šur tur eksperimentējam ar TokuDB kas izmanto fractal tree indeksu tādējādi (vismaz developeri apgalvo) nedefragmentējas (bet ir protams citas ķeskas).

Tikai pēc ši kverija: red_loc tabulai nepieciešams indeks uz 'id' lauka red_seo tabulai uz 'popular' lauka.

Bet īsumā pieredze/domas ir šādas (secībai nav nozīme): - MongoDB ir interesants produkts - viegli/ātri uzliekams un samērā vienkārši uzsākt lietot - Autoto(cluster)scalings reizē ir spožums un posts - ir jauki ka dinamiski iespējams audzēt datubāzi/klusteri "dzīvajā" un aplikācijai par to nav nojausmas, bet tad sākas problēmas ar shard keyiem / chunku migraacijaam utt - Ir forši monitoringa rīki ( https://www.mongodb.com/cloud/ ) Pieredze ir apmēram tāda: - bija paliels risinājums/db (pāris miljardi ierakstu) kas strādāja uz sadalīta (3 instances) MySQL (shārdots aplikācijas pusē) ~ kopā apjoms bija ap 800 Gb +- - jaunu fīču un vajadzību dēļ tika pieņemts lēmums pāriet (mēģināt) uz Mongo sanāca (3 x 3 cluster instances (MongoDB nepieciešamas 3 replicas lai pieņemtu lēmumus) + apjoms izauga uz kādiem 2Tb (jo tanī brīdī 2.4-2.6.x Mongo nebija nekādu kompresijas iespēju - bija TokuMX, taču tas īsti nestrādāja kopā ar parastajām Mongo instancēm (dažādi oplog formāti) - 3.x Mongo parādijās WiredTiger engine ar kompresiju, bet tad vilciens jau bija garām) - Tad kādu laiku tika lietots šis risinājums, taču dažādu iemeslu dēļ (nepārdomātas dokumentu struktūras - iekritām uz 16Mb dokumentu limitu utt) un visumā diezgan randomizētas performances (dažādu chunku migrācijas laikā varēja sanākt visādi) - līdz ar to ne prieka ne patikas - Risinājums tika pārtaisīts atpakaļ uz MySQL + TokuDB engīni (ko tagad nopirka Percona) un ir 1 db instance ar ~280Gb datiem (reālo datu apjoms ir tikai audzis) un viss notiek. Kaut kā tā ..

https://dev.mysql.com/doc/refman/5.7/en/json.html

Ja ir pietiekami jauna MySQL versija (sākot no 5.6.x) salīdzinoši daudzas operācijas notiek "onlainā" un kas it īpaši (reizēm) bez vecās tabulas pārkopēšanas: https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid

Īsumā - MySQL jēdzīgi māk izmantot tikai vienu tabulas indeksu (eksistē tur protams tagad visādas index-merge optimizācijas) bet in general ideja ir tāda - proti ja WHERE kolonna ir vienā indeksā bet ORDER vai GROUP kolonna ir citā indeksā tad ir "ziepes", atkarībā no mysql optimizera sajūtām var tikt izmantots tikai tas indekss kas ir WHERE nosacijumā un rezultāti kārtoti "fiziski" jebšu otrādi - mysql var izdomāt ka sasortēt tabulu ar miljons ierakstiem ir ātrāk un tad skriet tai cauri "manuāli" (row-by-row) pārbaudot katru vērtību un atlasīt tikai konkrētus ierakstus. Savukārt kombinētos indeksus lielam lauku skaitam ir sarežģīti uzlikt - piemēram, ja ir indeks uz (kolonna1,kollona2, kollona3) tad kverijs WHERE kolonna1 = 'lala', kolonna2='blabla', ODER BY kolonna3 ir OK, bet kverijs WHERE kolonna1 = 'lala', ODER BY kolonna3 vairs nē (proti indekss tiks izmantots, taču tikai atlasei, bet ne kārtošanai), tāpat WHERE kolonna2='blabla', ODER BY kolonna3 (šeit vispār nē) utt... Protams, ja kveriji ir vienmēr fiksēti (noteikti (un ne pārāk daudz variacijās) WHERE/ORDER nosacījumi) tad ir savādāk, bet praksē parasti nācies sastapties ar to ka tos WHERE/ORDER ik pa laikam maina vai arī nepieciešams tik dinamiski kārtot, ka puse no sākotnēji uzliktajiem tabulas indeksiem ir vai nu lieki vai pārklāj citus vai neizmantojas vispār. Tā kā bundža ar daudz tārpiem ..

Protams, tāpēc jau ir svarīgi ko, kā un kas ar tiem 500 laukiem jādara. Mans komentārs bija tikai par to, ka salīdzinājums nav visai korekts un kverijam: SELECT id FROM mega_tabula t WHERE (t.field1='v1' AND t.field2='v2') OR t.field3='v3' AND t.field4 LIKE '%v1%' ORDER BY t.field22 ASC, t.field150 DESC, nekādus sakarīgus indeksus ņemot verā MySQL īpatnības uzlikt nevar (ja tomēr, tad gribu noteikti redzēt (nopietni!) :) ) un nekāda "mežonīga" performance nebūs - protams, ja ieraksti būs zem < ~1mio (nu vai tabulas izmērs salien servera ramā (filecache)) un mysql instance nebūs kaut kāds diloņa slimnieks (nemaz nerunājot, ja kverijs iekešojas), tad protams izpildīsies arī samērojamā laikā (lasi, pietiekami ātri) jebšu tas saucas 'full table scan'.

Šis ir nekorekts salīdzinājums, jo neviens (parasti) tā netaisa. Tabula parasti ir tikai viena (nevis tabula1, tabula2, tabula500) un satur 3 laukus: objekta_id | propertija_nosaukums | propertija_vertiba Un tad selecteejot WHERE propertija_nosaukums = 'kautkas' AND propertija_vertiba = 'kautkaada' var atlasiit visus nepieciešamo objektu_id (kuriem tad piejono galveno tabulu(as) - attiecīgi tikai 1 JOINs) ..

Programmētāju ietiepība ar reizēm ir smieklīga (reizēm gan nāk dusmas u.c. izpausmes). Bet nu atbilde par to, kas ir labāks un ātrāks nav viennozīmīga, kaut vai dēļ šādiem jautājumiem: - Vai atlasīšanas kveriji ir jāveic pēc visiem 500 laukiem? Ja jā un ja tev ir 500 kolonnu tabula, tad arī no tādas selectējot pēc kaut kādiem 5 laukiem kverijs būs "lēns", jo lai gan tagad ir nedaudz labāka situācija ( https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html) tad principā vai nu tev jātaisa tabulai 500 indeksi (pie kam innodb var būt tikai 64) vai jāizvēlas uz kuriem likt uz kuriem nē, bet galugalā pasākums nekāds ideāls nav. - Vai ieraksta visas vērtības/kolonnas vienmēr satur vērtību? Ja nē, tad atkarībā no tā kāds % ir aizpildījumam var tikt zaudēts diezgan daudz diskvietas. Tāpēc jau arī eksistē dažādi NoSQL, kā arī veidi tradicionālajās RDBMS ( piem https://mariadb.com/kb/en/mariadb/column_json/) kā optimālāk iebakstīt objektam 500 vērtības.

Tāds savdabīgs salīdzinājums sanāk, jebšu nav īsti skaidrs, kas šajā gadījumā uzskatāms par būtisku (tehniskās "fīčas" vai izmaksas, vai lietojamība utt) .. Parse principā ir Facebook ownots MongoDB ( https://www.mongodb.org/) +RocksDB ( http://rocksdb.org/) object storage serviss, kam ir uzrakstīts kaut kāds API vs relāciju datubāze (kurai arī eksistē N dažādi servisi, kas piedāvā hostingu/menedžmentu utt). Atbilde noteikti nav viennozīmīga, proti, eksistē gadījumi/projekti, kur izdevīgāk un vienkāršāk visu backendu (vai pat frontendu (piemēram, daudzi tak izmanto tādas lietas kā jquery to pašu laravel nevis raksta visu no 0 utt)) atstāt 3rd-party ziņā, bet citos vai nu tas paliek nesamērīgi dārgi vai nemaz nav iespējams un tiek zaudēta kontrole.

Nezinu, pamēģini. Bet pirms rakstīt procedūras var jau patestēt arī vienkārši ar pašiem SQL kverijiem vai tie izpildās. Piemēram, no mysql konsoles vai kāda cita rīka (no phpmyadmin visdrīzāk nestrādās, jo nepieciešama nepārtraukta sesija) ar visiem mainīgajiem (@ ir sesijas mainīgie): SET @uid = 64437; SELECT `Password` INTO @passw FROM m_membership WHERE userid = @uid; UPDATE m_membership SET `Password` = 'rxSBeIf95nEjrYsvuqI1111tORgrsQ+SDcGfTob6pIQ=' WHERE userid = @uid; UPDATE m_membership SET `Password` = @passw WHERE userid = @uid; .. un tad skatīties kur un kas izpildās vai nē.

Mongodb parasti noklusēti (līdz šim) ir bez autorizācijas, attiecīgi droši vien nepieciešams kaut kāds firewalls vai konfigurēt/pārbaudīt lai klausās tikai uz localhost/127.0.0.1 interfeisu.

Viena lieta, kas krīt acī, ir Password, kas idejiski ir MySQL rezervēts vārds.. varbūt jālieto `Password` Otra - SELECT passw = Password FROM m_membership where userid = uid; sintakse varbūt, ka ir pareiza/ejoša, bet es personīgi esmu pieradis kaut kā lietot SELECT INTO -> SELECT `Password` INTO passw FROM m_membership where userid = uid; vai SET passw := ( SELECT `Password` FROM m_membership where userid = uid );

Idejiski Apache (ja ir nokompilēta ar mod_dir) noklusēti redirektē no site.com/dir uz site.com/dir/ ( http://httpd.apache.org/docs/2.4/mod/mod_dir.html#directoryslash ) Bet nu ja tieši ar rewraitu vajag tad kaut kā tā: RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+[^/])$ $1/ [R]

Pa lielam ir jakonfigurē darbstacijas pārlūki ( https://ping.force.com/Support/PingFederate/Integrations/How-to-configure-supported-browsers-for-Kerberos-NTLM) uz dažādiem OS/pārlūkiem var sanākt dažādi (piemēram FF eksistē kaut kas šāds https://bugzilla.mozilla.org/show_bug.cgi?id=554122 ) Un Apachei pielikt mod_auth_ntlm_winbind ( http://adldap.sourceforge.net/wiki/doku.php?id=mod_auth_ntlm_winbind ) un kasīt no tā laukā.

Jau tagad.. .. piemēram, visai nesen nācās uz servera mainīt php ekstensiju (memcache -> memached) tikai tāpēc, ka programmētājs nespēj freimworkam (kā reiz Laravelam) atrast/uzkodēt atbalstu esošajai $^DD%DF

Orākuļa konekcijas testiem vismaz kādreiz izmantoja tnsping (nāca kopā ar orākula klientu). Bet nu Tomcatam vajadzētu būt logiem pēc kuriem tad varētu spriest kas par šaizi notiek.

Nu ar šādu atbildi nesaprotu kāpēc iebilsti par scalu ... :E