یک نکته: آسان کردن دریافت معیارهای کسبوکار
مدلسازی داده سخت است. در اینجا برخی اشتباهات برای اجتناب هنگام توسعه مدلهای خود وجود دارد.
اشتباهات رایج مدل داده انجام شده توسط استارتاپها
مدلسازی داده سخت است. در اینجا برخی اشتباهات برای اجتناب هنگام توسعه مدلهای خود وجود دارد.
پس از کمک به ساخت stackهای تحلیلی چند استارتاپ، شروع به دیدن برخی الگوها میکنید. گاهی اوقات این الگوها خوشحالکننده هستند: تقریباً همه لحظهای را دوست دارند که از نداشتن ایده درباره آنچه اتفاق میافتد، به داشتن یک ایده مهآلود از آنچه هفته گذشته اتفاق افتاد میروید. الگوهای دیگر کمتر عالی هستند، و معمولاً شامل تصمیمات حول مدلهای داده یا schemaها میشوند.
مهم است توجه داشته باشید که anti-patternهایی که در زیر بحث میکنیم خاص استارتاپها هستند. برخی از این الگوها در واقع ایدههای خوبی برای شرکتهای مرحله بعدی هستند، اما برای استارتاپهای کوچک، قبل از product-market-fit، محدود به منابع، این اشتباهاتی هستند که نیاز به انجام ندارید.
بدون ado بیشتر، در اینجا پنج منبع اصلی درد در تحلیل مرحله اولیه وجود دارد:
1. آلوده کردن پایگاه داده خود با داده تست یا جعلی
چه حسابهای تست، حسابهای کارکنان، برنامههای داده مختلف، یا سفارشهایی که از طریق تلهپاتی گربهای میآیند، بیش از حد شرکتها دادهای را شامل میکنند که نیاز به نادیده گرفتن رویدادها یا تراکنشهای خاص در بسیاری یا بیشتر پرسوجوهای شما دارد.
با آلوده کردن پایگاه داده خود با داده تست، یک مالیات روی همه تحلیل (و ساخت ابزار داخلی) در شرکت خود معرفی کردهاید. میتوانید این مالیات را در برابر کارایی تراکنشی، یا بهرهوری توسعهدهنده متعادل کنید. گاهی اوقات این مالیات ارزش دارد، گاهی اوقات ندارد. برای شرکتهای بزرگ، کارایی تراکنشی یک هدف به اندازه کافی مهم است که میتوانید زمان چند مهندس یا تحلیلگر را برای پاک کردن نتایج هزینه کنید.
اگر کوچک هستید، احتمالاً نمیتوانید این را بپردازید، و احتمالاً باید tradeoff را جای دیگری انجام دهید.
2. بازسازی sessionها post hoc
بخش قابل توجهی از سؤالهای مهم حول رفتار کاربر، رضایت، و ارزش حول معیارهای session میچرخند. چه "sessionها"، "مکالمات"، "تماسهای پشتیبانی"، یا چیز دیگری نامیده شوند، این معیارها به تعدادی رویداد گسسته مرتبط با یک کاربر که باید با هم گروهبندی شوند و به عنوان یک مفهوم واحد در نظر گرفته شوند اشاره میکنند. با این حال، به طور ترسناکی رایج است که مدلهای داده استارتاپها در گرفتن این مفهوم پایه در واژگان یک کسبوکار شکست بخورند.
Sessionها اغلب post hoc (یعنی پس از واقعیت) بازسازی میشوند، که معمولاً منجر به شکنندگی و درد زیادی میشود. تعریف دقیق آنچه یک session را تشکیل میدهد معمولاً با تغییر خود اپلیکیشن تغییر میکند. علاوه بر این، اغلب context زیادی حول session یک کاربر در کلاینت، یا سرور پردازش درخواستهای کلاینت وجود دارد. خیلی آسانتر است یک session، تیکت پشتیبانی، یا ID مکالمه را در اپلیکیشن خود اختصاص دهید تا اینکه سعی کنید یک session را پس از واقعیت بازسازی کنید.
3. حذفهای نرم
در مقیاس، حذف ردیفها در یک پایگاه داده تحت بار قابل توجه چیز بدی است. حذفهای نرم یک ابزار schema رایج است که ضربههای عملکرد حذف، و compaction بعدی (یا vacuuming) را کاهش میدهد. علاوه بر این، حذفهای نرم آسان کردن حذف نکردن ردیفها برای بازیابی داده حذف شده را آسان میکند.
در طرف دیگر، حذفهای نرم نیاز دارند هر پرسوجوی خواندن واحد رکوردهای حذف شده را مستثنی کند. اگر فقط فراخوانیهای داده اپلیکیشن را در نظر بگیرید، ممکن است خیلی بد به نظر نرسد. با این حال، وقتی در همه پرسوجوهای تحلیلی که اجرا خواهید کرد ضرب میشود، این استثنا به سرعت شروع به تبدیل شدن به یک drag جدی میکند. آن، و حذفهای نرم مکان دیگری را معرفی میکنند جایی که کاربران مختلف میتوانند فرضیات مختلفی داشته باشند، که میتواند منجر به اعداد ناسازگار شود که نیاز به debug کردن دارید.
4. سوء استفاده از داده نیمهساختار یافته
داده نیمهساختار یافته (مثلاً فیلدهای کدگذاری شده به عنوان JSON) میتواند در موقعیتهایی که تعدادی ساختار مختلف در طول زمان وجود دارد مفید باشد. همانطور که پایگاههای داده بزرگتر میشوند، داده نیمهساختار یافته همچنین میتواند به اجتناب از دردسرهای migrate کردن جداول بزرگ تحت بار خواندن یا نوشتن سنگین کمک کند.
با این حال، داده نیمهساختار یافته همچنین میتواند منجر به سوزش قلب زیادی هنگام تلاش برای دریافت داده از یک پایگاه داده شود. معمولاً داده نیمهساختار یافته schemaهایی دارند که فقط توسط convention اعمال میشوند، که ممکن است به طور غیرقابل پیشبینی تغییر کنند، یا به دلیل bugهای گذرا خاموش باشند، و به طور کلی نیاز به پاک کردن post hoc زیادی برای مفید بودن دارند.
و گاهی اوقات فیلدهای داده نیمهساختار یافته بهانهای برای punt کردن روی فکر کردن از طریق ساختاری که نیاز دارید تا پس از نوشتن یک ویژگی هستند. در این مورد، در واقع داده ساختار یافته دارید، فقط اعمال نشده، مستعد bug، و به طور کلی درد استفاده است. یک تست ساده: اگر هر نمونه از یک فیلد JSON همان چهار فیلد را دارد، احتمالاً باید ساختار را تجزیه کنید.
5. سندرم "پایگاه داده درست برای کار"
وجود تعداد زیادی پایگاه داده مختلف استفاده شده در stack فناوری یک شرکت معمولاً یکی از سه سناریو را نشان میدهد:
- یک شرکت واقعاً عظیم، پیچیده که نیازها و بخشهای متنوعی دارد.
- یک تیم مهندسی و عملیاتی به شدت عملکردی، با عملکرد بالا که روی مشکلات بسیار دشوار کار میکند که نیاز به بهینهسازی به شدت همه جنبههای اپ دارد.
- (بیشتر اوقات) یک تیم کوچک که به طور مداوم آتشها را در فناوریهایی که فقط به طور سطحی درک میکند خاموش میکند.
با هر پایگاه داده اضافی که اضافه میکنید، overhead عملیاتی زیادی به عهده میگیرید. آن، و هر پایگاه داده اضافی مجموعه داده دیگری است که نیاز به قرار دادن در یک پایگاه داده تحلیلی دارید. این پایگاههای داده semantics، انواع داده، و مدلهای داده طبیعی کمی متفاوت خواهند داشت که باید حل کنید.
پس در برابر میل به آسان کردن پیادهسازی یک ویژگی کوچک مقاومت کنید، چون عملیات و تحلیل را در سراسر تخته خیلی سختتر میکنید.
یک نکته: آسان کردن دریافت معیارهای کسبوکار
هنگام فکر کردن از طریق اینکه آیا مدل داده شما نیازهای تحلیلی و تراکنشی شما را در نظر میگیرد، مفید است موارد زیر را شناسایی کنید:
- 10 معیار مهم که کسبوکار به آنها اهمیت میدهد
- 10 پرسوجوی بهروزرسانی که بیشتر اوقات از اپلیکیشن اجرا میشوند
- 10 الگوی خواندن رایج از اپلیکیشن
به دنبال یک مدل داده هستید که درد را در همه این پرسوجوهای متمایز به حداقل برساند. به طور کلی، پرسوجوها برای معیارهای کسبوکار مهمترین هستند، پس اگر معرفی کمی پیچیدگی برای بهروزرسانیها و خواندن اپلیکیشن پرسوجو برای معیارهای کسبوکار را آسانتر میکند، انجام دهید. بهرهوری کلی را به حداکثر میرسانید، چون معمولاً پرسوجوهای workhorse بسیار کمتری در سمت اپلیکیشن نسبت به سؤالهای تحلیلی یا هوش کسبوکار رایج وجود دارد.
همچنین، پرسوجوها برای اپلیکیشن معمولاً در کنترل منبع انجام میشوند، در تست خودکار پیچیده میشوند، و به طور کلی خیلی بیشتر hardened هستند. پرسوجوها برای معیارهای کسبوکار معمولاً پراکنده، نوشته شده توسط افراد زیادی، و به طور کلی خیلی کمتر کنترل شده هستند. پس کاری که میتوانید انجام دهید تا کسبوکار شما معیارهایی که نیاز به تصمیمگیری بهتر دارد را به راحتی دریافت کند انجام دهید.