Zamonaviy protsessorlar juda ko'p yadrolarga ega. Ko'p yillar davomida ilovalar ma'lumotlar bazalariga parallel ravishda so'rovlarni yuborib kelmoqda. Agar bu jadvaldagi bir nechta satrlar bo'yicha hisobot so'rovi bo'lsa, u bir nechta protsessorlardan foydalanganda tezroq ishlaydi va PostgreSQL buni 9.6 versiyasidan boshlab amalga oshira oldi.
Parallel so‘rov funksiyasini amalga oshirish uchun 3 yil kerak bo‘ldi – so‘rovni bajarishning turli bosqichlarida kodni qayta yozishga to‘g‘ri keldi. PostgreSQL 9.6 kodni yanada yaxshilash uchun infratuzilmani joriy qildi. Keyingi versiyalarda boshqa turdagi so'rovlar parallel ravishda bajariladi.
Cheklovlar
- Agar barcha yadrolar allaqachon band bo'lsa, parallel bajarishni yoqmang, aks holda boshqa so'rovlar sekinlashadi.
- Eng muhimi, yuqori WORK_MEM qiymatlari bilan parallel ishlov berish juda ko'p xotiradan foydalanadi - har bir xeshni qo'shish yoki tartiblash work_mem xotirasini egallaydi.
- Past kechikishli OLTP so'rovlarini parallel bajarish orqali tezlashtirish mumkin emas. Va agar so'rov bitta qatorni qaytarsa, parallel ishlov berish uni faqat sekinlashtiradi.
- Ishlab chiquvchilar TPC-H benchmarkidan foydalanishni yaxshi ko'radilar. Ehtimol, sizda mukammal parallel bajarish uchun shunga o'xshash so'rovlar mavjud.
- Faqat predikat blokirovkasisiz SELECT so'rovlari parallel ravishda bajariladi.
- Ba'zan to'g'ri indekslash parallel rejimda jadvallarni ketma-ket skanerlashdan ko'ra yaxshiroqdir.
- So'rovlar va kursorlarni to'xtatib turish qo'llab-quvvatlanmaydi.
- Oyna funktsiyalari va tartiblangan to'plamni yig'ish funktsiyalari parallel emas.
- I/U ish yukida siz hech narsaga erishmaysiz.
- Parallel tartiblash algoritmlari mavjud emas. Ammo sortlarga ega so'rovlar ba'zi jihatlarda parallel ravishda bajarilishi mumkin.
- Parallel ishlov berishni yoqish uchun CTE (WITH ...) ni ichki SELECT bilan almashtiring.
- Uchinchi tomon ma'lumotlar paketlari hali parallel ishlov berishni qo'llab-quvvatlamaydi (lekin ular mumkin!)
- FULL OUTER JOIN qo‘llab-quvvatlanmaydi.
- max_rows parallel ishlov berishni o'chiradi.
- Agar so'rovda PARALLEL SAFE deb belgilanmagan funksiya bo'lsa, u bitta tishli bo'ladi.
- SERIALIZABLE tranzaksiyani izolyatsiyalash darajasi parallel ishlov berishni o'chiradi.
Sinov muhiti
PostgreSQL ishlab chiquvchilari TPC-H benchmark so'rovlariga javob berish vaqtini qisqartirishga harakat qilishdi. Benchmarkni yuklab oling va . Bu TPC-H benchmarkidan norasmiy foydalanish - ma'lumotlar bazasi yoki apparat solishtirish uchun emas.
- TPC-H_Tools_v2.17.3.zip (yoki yangiroq versiyasi) yuklab oling .
- makefile.suite nomini Makefile qilib o'zgartiring va bu erda tasvirlanganidek o'zgartiring: . make buyrug'i bilan kodni kompilyatsiya qiling.
- Ma'lumotlarni yaratish:
./dbgen -s 1023 GB hajmli ma'lumotlar bazasini yaratadi. Bu parallel va parallel bo'lmagan so'rovlarning ishlashidagi farqni ko'rish uchun etarli. - Fayllarni aylantirish
tblвcsv с forиsed. - Repozitariyni klonlash
pg_tpchva fayllarni nusxalashcsvвpg_tpch/dss/data. - Buyruq yordamida so'rovlar yarating
qgen. - Buyruq yordamida ma'lumotlarni ma'lumotlar bazasiga yuklang
./tpch.sh.
Parallel ketma-ket skanerlash
Bu parallel o'qish tufayli emas, balki ma'lumotlar ko'plab CPU yadrolari bo'ylab tarqalganligi sababli tezroq bo'lishi mumkin. Zamonaviy operatsion tizimlarda PostgreSQL ma'lumotlar fayllari yaxshi keshlangan. Oldinda o'qish bilan, saqlashdan PG daemon so'rovlariga qaraganda kattaroq blokni olish mumkin. Shuning uchun so'rovlarning ishlashi diskdagi kiritish-chiqarish bilan cheklanmaydi. U CPU davrlarini quyidagilar uchun sarflaydi:
- jadval sahifalaridan qatorlarni birma-bir o'qish;
- satr qiymatlari va shartlarini solishtiring
WHERE.
Keling, oddiy so'rovni bajaraylik select:
tpch=# explain analyze select l_quantity as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Seq Scan on lineitem (cost=0.00..1964772.00 rows=58856235 width=5) (actual time=0.014..16951.669 rows=58839715 loops=1)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 1146337
Planning Time: 0.203 ms
Execution Time: 19035.100 msKetma-ket skanerlash birlashtirmasdan juda ko'p qatorlarni hosil qiladi, shuning uchun so'rov bitta CPU yadrosi tomonidan bajariladi.
Qo'shsangiz SUM(), ikkita ish jarayoni so'rovni tezlashtirishga yordam berishini ko'rishingiz mumkin:
explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 msParallel yig'ish
Parallel Seq Scan tuguni qisman yig'ish uchun qatorlarni ishlab chiqaradi. "Qisman yig'ish" tugunlari yordamida bu qatorlarni kesadi SUM(). Oxir-oqibat, har bir ishchi jarayonidan SUM hisoblagichi "Yig'ish" tuguni tomonidan yig'iladi.
Yakuniy natija "Finalize Aggregate" tuguni tomonidan hisoblanadi. Agar sizda o'zingizning yig'ish funksiyalaringiz bo'lsa, ularni "parallel xavfsiz" deb belgilashni unutmang.
Ishchi jarayonlar soni
Serverni qayta ishga tushirmasdan ishchi jarayonlar sonini oshirish mumkin:
explain analyze select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=1589702.14..1589702.15 rows=1 width=32) (actual time=8553.365..8553.365 rows=1 loops=1)
-> Gather (cost=1589701.91..1589702.12 rows=2 width=32) (actual time=8553.241..8555.067 rows=3 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Partial Aggregate (cost=1588701.91..1588701.92 rows=1 width=32) (actual time=8547.546..8547.546 rows=1 loops=3)
-> Parallel Seq Scan on lineitem (cost=0.00..1527393.33 rows=24523431 width=5) (actual time=0.038..5998.417 rows=19613238 loops=3)
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 382112
Planning Time: 0.241 ms
Execution Time: 8555.131 msBu yerda nima bo'lyapti? Ish jarayonlari 2 barobar ko'p bo'ldi va so'rov atigi 1,6599 marta tezlashdi. Hisob-kitoblar qiziqarli. Bizda 2 ishchi jarayoni va 1 rahbar bor edi. O'zgarishdan keyin u 4+1 bo'ldi.
Parallel ishlov berishdan maksimal tezligimiz: 5/3 = 1,66 (6) marta.
U qanday ishlaydi?
Jarayonlar
So'rovni bajarish har doim etakchi jarayondan boshlanadi. Rahbar hamma narsani parallel bo'lmagan va ba'zi parallel ishlov berishni amalga oshiradi. Xuddi shu so'rovlarni bajaradigan boshqa jarayonlar ishchi jarayonlar deb ataladi. Parallel ishlov berish infratuzilmadan foydalanadi (9.4 versiyasidan). PostgreSQL ning boshqa qismlari iplardan ko'ra jarayonlardan foydalanganligi sababli, 3 ishchi jarayonidan iborat so'rov an'anaviy ishlov berishdan 4 baravar tezroq bo'lishi mumkin.
O'zaro aloqalar
Ishchi jarayonlari rahbar bilan xabarlar navbati orqali muloqot qiladi (umumiy xotira asosida). Har bir jarayonda 2 ta navbat bor: xatolar va kortejlar uchun.
Qancha ish jarayoni kerak?
Minimal chegara parametr bilan belgilanadi . So'rov bajaruvchisi parametr bilan cheklangan hovuzdan ishchi jarayonlarni oladi . Oxirgi cheklov , ya'ni fon jarayonlarining umumiy soni.
Agar ishchi jarayonini ajratishning iloji bo'lmasa, qayta ishlash bir jarayonli bo'ladi.
So'rovni rejalashtiruvchi jadval yoki indeks hajmiga qarab ish oqimlarini kamaytirishi mumkin. Buning uchun parametrlar mavjud и .
set min_parallel_table_scan_size='8MB'
8MB table => 1 worker
24MB table => 2 workers
72MB table => 3 workers
x => log(x / min_parallel_table_scan_size) / log(3) + 1 workerHar safar stol 3 barobar kattaroq min_parallel_(index|table)_scan_size, Postgres ishchi jarayonini qo'shadi. Ish oqimlari soni xarajatlarga asoslanmaydi. Doiraviy qaramlik murakkab amalga oshirishni qiyinlashtiradi. Buning o'rniga, rejalashtiruvchi oddiy qoidalardan foydalanadi.
Amalda, ushbu qoidalar har doim ishlab chiqarish uchun mos emas, shuning uchun siz ma'lum bir jadval uchun ishchi jarayonlar sonini o'zgartirishingiz mumkin: ALTER TABLE ... SET (parallel_workers = N).
Nima uchun parallel ishlov berish ishlatilmaydi?
Cheklovlarning uzoq ro'yxatidan tashqari, xarajatlarni tekshirish ham mavjud:
- qisqa so'rovlarni parallel qayta ishlashga yo'l qo'ymaslik. Ushbu parametr xotirani tayyorlash, jarayonni boshlash va dastlabki ma'lumotlar almashinuvi vaqtini taxmin qiladi.
: rahbar va ishchilar o'rtasidagi aloqa ish jarayonlaridan kortejlar soniga mutanosib ravishda kechiktirilishi mumkin. Ushbu parametr ma'lumotlar almashinuvi narxini hisoblab chiqadi.
Ichki tsikl qo'shiladi
PostgreSQL 9.6+ может выполнять вложенные циклы параллельно — это простая операция.
explain (costs off) select c_custkey, count(o_orderkey)
from customer left outer join orders on
c_custkey = o_custkey and o_comment not like '%special%deposits%'
group by c_custkey;
QUERY PLAN
--------------------------------------------------------------------------------------
Finalize GroupAggregate
Group Key: customer.c_custkey
-> Gather Merge
Workers Planned: 4
-> Partial GroupAggregate
Group Key: customer.c_custkey
-> Nested Loop Left Join
-> Parallel Index Only Scan using customer_pkey on customer
-> Index Scan using idx_orders_custkey on orders
Index Cond: (customer.c_custkey = o_custkey)
Filter: ((o_comment)::text !~~ '%special%deposits%'::text)To'plam oxirgi bosqichda sodir bo'ladi, shuning uchun Nested Loop Left Join parallel operatsiya hisoblanadi. Parallel Index Only Scan faqat 10-versiyada joriy qilingan. U parallel ketma-ket skanerlash kabi ishlaydi. Vaziyat c_custkey = o_custkey mijoz qatoriga bitta buyurtmani o'qiydi. Demak, bu parallel emas.
Xash qo'shilish
Har bir ishchi jarayon PostgreSQL 11 ga qadar o'z xesh-jadvalini yaratadi. Va agar bu jarayonlarning to'rttadan ko'pi bo'lsa, unumdorlik yaxshilanmaydi. Yangi versiyada xesh jadvali almashiladi. Har bir ishchi jarayon xesh jadvalini yaratish uchun WORK_MEM dan foydalanishi mumkin.
select
l_shipmode,
sum(case
when o_orderpriority = '1-URGENT'
or o_orderpriority = '2-HIGH'
then 1
else 0
end) as high_line_count,
sum(case
when o_orderpriority <> '1-URGENT'
and o_orderpriority <> '2-HIGH'
then 1
else 0
end) as low_line_count
from
orders,
lineitem
where
o_orderkey = l_orderkey
and l_shipmode in ('MAIL', 'AIR')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= date '1996-01-01'
and l_receiptdate < date '1996-01-01' + interval '1' year
group by
l_shipmode
order by
l_shipmode
LIMIT 1;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=1964755.66..1964961.44 rows=1 width=27) (actual time=7579.592..7922.997 rows=1 loops=1)
-> Finalize GroupAggregate (cost=1964755.66..1966196.11 rows=7 width=27) (actual time=7579.590..7579.591 rows=1 loops=1)
Group Key: lineitem.l_shipmode
-> Gather Merge (cost=1964755.66..1966195.83 rows=28 width=27) (actual time=7559.593..7922.319 rows=6 loops=1)
Workers Planned: 4
Workers Launched: 4
-> Partial GroupAggregate (cost=1963755.61..1965192.44 rows=7 width=27) (actual time=7548.103..7564.592 rows=2 loops=5)
Group Key: lineitem.l_shipmode
-> Sort (cost=1963755.61..1963935.20 rows=71838 width=27) (actual time=7530.280..7539.688 rows=62519 loops=5)
Sort Key: lineitem.l_shipmode
Sort Method: external merge Disk: 2304kB
Worker 0: Sort Method: external merge Disk: 2064kB
Worker 1: Sort Method: external merge Disk: 2384kB
Worker 2: Sort Method: external merge Disk: 2264kB
Worker 3: Sort Method: external merge Disk: 2336kB
-> Parallel Hash Join (cost=382571.01..1957960.99 rows=71838 width=27) (actual time=7036.917..7499.692 rows=62519 loops=5)
Hash Cond: (lineitem.l_orderkey = orders.o_orderkey)
-> Parallel Seq Scan on lineitem (cost=0.00..1552386.40 rows=71838 width=19) (actual time=0.583..4901.063 rows=62519 loops=5)
Filter: ((l_shipmode = ANY ('{MAIL,AIR}'::bpchar[])) AND (l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND (l_receiptdate >= '1996-01-01'::date) AND (l_receiptdate < '1997-01-01 00:00:00'::timestamp without time zone))
Rows Removed by Filter: 11934691
-> Parallel Hash (cost=313722.45..313722.45 rows=3750045 width=20) (actual time=2011.518..2011.518 rows=3000000 loops=5)
Buckets: 65536 Batches: 256 Memory Usage: 3840kB
-> Parallel Seq Scan on orders (cost=0.00..313722.45 rows=3750045 width=20) (actual time=0.029..995.948 rows=3000000 loops=5)
Planning Time: 0.977 ms
Execution Time: 7923.770 msTPC-H dan 12-so'rov parallel xesh ulanishini aniq ko'rsatadi. Har bir ishchi jarayon umumiy xesh jadvalini yaratishga hissa qo'shadi.
Birlashtiring
Birlashtirish tabiatan parallel emas. Agar bu so'rovning oxirgi bosqichi bo'lsa, tashvishlanmang - u hali ham parallel ravishda ishlashi mumkin.
-- Query 2 from TPC-H
explain (costs off) select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
from part, supplier, partsupp, nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 36
and p_type like '%BRASS'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
and ps_supplycost = (
select
min(ps_supplycost)
from partsupp, supplier, nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
)
order by s_acctbal desc, n_name, s_name, p_partkey
LIMIT 100;
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Limit
-> Sort
Sort Key: supplier.s_acctbal DESC, nation.n_name, supplier.s_name, part.p_partkey
-> Merge Join
Merge Cond: (part.p_partkey = partsupp.ps_partkey)
Join Filter: (partsupp.ps_supplycost = (SubPlan 1))
-> Gather Merge
Workers Planned: 4
-> Parallel Index Scan using <strong>part_pkey</strong> on part
Filter: (((p_type)::text ~~ '%BRASS'::text) AND (p_size = 36))
-> Materialize
-> Sort
Sort Key: partsupp.ps_partkey
-> Nested Loop
-> Nested Loop
Join Filter: (nation.n_regionkey = region.r_regionkey)
-> Seq Scan on region
Filter: (r_name = 'AMERICA'::bpchar)
-> Hash Join
Hash Cond: (supplier.s_nationkey = nation.n_nationkey)
-> Seq Scan on supplier
-> Hash
-> Seq Scan on nation
-> Index Scan using idx_partsupp_suppkey on partsupp
Index Cond: (ps_suppkey = supplier.s_suppkey)
SubPlan 1
-> Aggregate
-> Nested Loop
Join Filter: (nation_1.n_regionkey = region_1.r_regionkey)
-> Seq Scan on region region_1
Filter: (r_name = 'AMERICA'::bpchar)
-> Nested Loop
-> Nested Loop
-> Index Scan using idx_partsupp_partkey on partsupp partsupp_1
Index Cond: (part.p_partkey = ps_partkey)
-> Index Scan using supplier_pkey on supplier supplier_1
Index Cond: (s_suppkey = partsupp_1.ps_suppkey)
-> Index Scan using nation_pkey on nation nation_1
Index Cond: (n_nationkey = supplier_1.s_nationkey)"Birlashtirish birlashma" tugun "Birlashtirish yig'ish" ustida joylashgan. Shunday qilib, birlashish parallel ishlov berishdan foydalanmaydi. Ammo "Parallel indeksni skanerlash" tugunlari hali ham segmentga yordam beradi part_pkey.
Bo'limlar bo'yicha ulanish
PostgreSQL 11 da sukut bo'yicha o'chirilgan: u juda qimmat rejalashtirishga ega. Shunga o'xshash qismlarga ega jadvallarni qismlarga bo'lish mumkin. Shunday qilib, Postgres kichikroq xesh jadvallaridan foydalanadi. Bo'limlarning har bir ulanishi parallel bo'lishi mumkin.
tpch=# set enable_partitionwise_join=t;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
QUERY PLAN
---------------------------------------------------
Append
-> Hash Join
Hash Cond: (t2.b = t1.a)
-> Seq Scan on prt2_p1 t2
Filter: ((b >= 0) AND (b <= 10000))
-> Hash
-> Seq Scan on prt1_p1 t1
Filter: (b = 0)
-> Hash Join
Hash Cond: (t2_1.b = t1_1.a)
-> Seq Scan on prt2_p2 t2_1
Filter: ((b >= 0) AND (b <= 10000))
-> Hash
-> Seq Scan on prt1_p2 t1_1
Filter: (b = 0)
tpch=# set parallel_setup_cost = 1;
tpch=# set parallel_tuple_cost = 0.01;
tpch=# explain (costs off) select * from prt1 t1, prt2 t2
where t1.a = t2.b and t1.b = 0 and t2.b between 0 and 10000;
QUERY PLAN
-----------------------------------------------------------
Gather
Workers Planned: 4
-> Parallel Append
-> Parallel Hash Join
Hash Cond: (t2_1.b = t1_1.a)
-> Parallel Seq Scan on prt2_p2 t2_1
Filter: ((b >= 0) AND (b <= 10000))
-> Parallel Hash
-> Parallel Seq Scan on prt1_p2 t1_1
Filter: (b = 0)
-> Parallel Hash Join
Hash Cond: (t2.b = t1.a)
-> Parallel Seq Scan on prt2_p1 t2
Filter: ((b >= 0) AND (b <= 10000))
-> Parallel Hash
-> Parallel Seq Scan on prt1_p1 t1
Filter: (b = 0)Asosiysi, bo'limlardagi ulanish faqat bu qismlar etarlicha katta bo'lsa, parallel bo'ladi.
Parallel qo'shish
turli ish oqimlarida turli bloklar o'rniga foydalanish mumkin. Bu odatda UNION ALL so'rovlari bilan sodir bo'ladi. Kamchilik - kamroq parallellik, chunki har bir ishchi jarayon faqat 1 ta so'rovni qayta ishlaydi.
Bu yerda 2 ta ishchi jarayoni ishlaydi, ammo 4 tasi yoqilgan.
tpch=# explain (costs off) select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '1998-12-01' - interval '105' day union all select sum(l_quantity) as sum_qty from lineitem where l_shipdate <= date '2000-12-01' - interval '105' day;
QUERY PLAN
------------------------------------------------------------------------------------------------
Gather
Workers Planned: 2
-> Parallel Append
-> Aggregate
-> Seq Scan on lineitem
Filter: (l_shipdate <= '2000-08-18 00:00:00'::timestamp without time zone)
-> Aggregate
-> Seq Scan on lineitem lineitem_1
Filter: (l_shipdate <= '1998-08-18 00:00:00'::timestamp without time zone)Eng muhim o'zgaruvchilar
- WORK_MEM har bir jarayon uchun xotirani cheklaydi, faqat so'rovlarni emas: work_mem jarayonlari ulanishlar = juda ko'p xotira.
- — bajaruvchi dastur rejadan parallel ishlov berish uchun qancha ishchi jarayonlaridan foydalanadi.
- — ishchi jarayonlarning umumiy sonini serverdagi protsessor yadrolari soniga moslashtiradi.
- - xuddi shunday, lekin parallel ish jarayonlari uchun.
natijalar
9.6 versiyasidan boshlab, parallel ishlov berish ko'plab satrlar yoki indekslarni skanerlaydigan murakkab so'rovlarning ishlashini sezilarli darajada yaxshilaydi. PostgreSQL 10 da parallel ishlov berish sukut bo'yicha yoqilgan. Uni katta OLTP ish yukiga ega serverlarda o'chirib qo'yishni unutmang. Ketma-ket skanerlash yoki indeks skanerlash juda ko'p resurslarni sarflaydi. Agar siz butun ma'lumotlar to'plami bo'yicha hisobotni ishga tushirmasangiz, etishmayotgan indekslarni qo'shish yoki to'g'ri bo'limlardan foydalanish orqali so'rovlar samaradorligini oshirishingiz mumkin.
Manbalar
Manba: www.habr.com